jamesfredley opened a new pull request, #15612: URL: https://github.com/apache/grails-core/pull/15612
## Summary Eliminates the race condition in `FormTagLib2Tests.testDatePickerTag` that produced an intermittent `testDatePickerTagWithMinutePrecision()` failure on slow runners (most recently on `Build Grails-Core (windows-latest, 25)` in [PR #15467 / run 25170545020](https://github.com/apache/grails-core/actions/runs/25170545020/job/73788418508)). ## What was wrong `testDatePickerTag(Object date, String precision)` rendered the date-picker HTML first, then constructed a fresh `GregorianCalendar` afterwards to derive the expected select-field values. When the two calls fell on opposite sides of a minute (or hour/day/year) boundary, the picker output and the calendar disagreed, producing a flaky assertion such as: ``` FormTagLib2Tests > testDatePickerTagWithMinutePrecision() expected: <true> but was: <false> at org.grails.web.taglib.AbstractGrailsTagTests.assertXPathExists(AbstractGrailsTagTests.groovy:527) at FormTagLib2Tests.assertSelectFieldPresentWithSelectedValue(FormTagLib2Tests.groovy:307) at FormTagLib2Tests.validateSelectedMinuteValue(FormTagLib2Tests.groovy:297) at FormTagLib2Tests.testDatePickerTag(FormTagLib2Tests.groovy:237) ``` ## Fix Capture the calendar up-front and, when the test passes a `null` date, forward `calendar.getTime()` to the picker so both sides agree on a single instant. Behaviour for explicit `Date` arguments is unchanged. `getDatePickerOutput` simply forwards the supplied value to the `datePicker` tag, which itself defaults to `new Date()` when no value is provided, so passing the captured `calendar.getTime()` exercises the same code path as `null` did before but without the race window. ## Verification ``` ./gradlew :grails-gsp:test --tests org.grails.web.taglib.FormTagLib2Tests --rerun-tasks ``` All 11 tests pass on Windows (the runner that exhibited the original flake), including the previously flaky `testDatePickerTagWithMinutePrecision()`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
