-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hibernate ORM and Spring Data tests failing with out-by-one error when run on Mac in North American timezone #28035
Comments
These tests are not taking timezones properly into account, but they also don't really need to fully test the date handling, so we relax them a bit. Closes: quarkusio#28035
Although #28044 does not really answer why this is happening on M1 test runners, it nonetheless does allow us to progress |
Relax testing constraints on certain dates tests
Super-quick fix! Can this work item also take responsibility for reversing the changes made in #27156 to disable the tests, please? Otherwise it will be delaying #27156 because 27156 will need to be revised to un-disable the tests and then do another CI run. (I think delaying getting M1 into the build was perhaps the opposite of the intention of the changes here.) |
@holly-cummins done! I rebased and force pushed to your branch so the PR is updated |
Oh, sorry, @geoand , I meant the opposite! I meant could we leave my branch alone to improve the chances of a green run on that branch, and use this work item to track re-enabling the tests, after the M1 changes have merged. The M1 PR is struggling to get in so I was hoping to minimise further changes on that branch so I don't have to keep waiting for full-build cycles. Ah well! Hopefully tomorrow will be the day for the M1 PR (fingers crossed!) |
Oh, sorry! |
We still see some of date-related failures on M1, so this should perhaps be re-opened. Fixes would need to be tested with #28082:
|
These tests are not taking timezones properly into account, but they also don't really need to fully test the date handling, so we relax them a bit. Closes: quarkusio#28035 (cherry picked from commit a6e79ff)
These tests are not taking timezones properly into account, but they also don't really need to fully test the date handling, so we relax them a bit. Closes: quarkusio#28035
These tests are not taking timezones properly into account, but they also don't really need to fully test the date handling, so we relax them a bit. Closes: quarkusio#28035
These tests are not taking timezones properly into account, but they also don't really need to fully test the date handling, so we relax them a bit. Closes: quarkusio#28035
These tests are not taking timezones properly into account, but they also don't really need to fully test the date handling, so we relax them a bit. Closes: quarkusio#28035
Is this still an issue? |
I suspect it is, and that we don't see it every day because the tests are disabled. I've rebased #28082 (which enables the tests and shows the problem) to force a new build so we can check. |
Great, thanks |
Confirming this is still an issue. https://github.com/quarkusio/quarkus/runs/9674074039 shows the problem. It's been dealt with at the moment by disabling the tests, which isn't ideal for a number of reasons.
To expose the problem:
|
When I see such funny date blunders, one part of me grins, the other part wonders if it's "our" fault :) |
cc @aureamunoz I add it to my backlog for checking |
Describe the bug
I can’t decide if this is a test issue, or an implementation issue, but I’m raising a defect to track the investigation (and track the disabling of the tests on Mac CIs in #27156, which we will want to reverse once this is sorted out).
A number of tests which check author.dob are failing with an out-by-one error, on our Mac GitHub runner. I assume the issue is a timezone one, since taking five hours off a date (as in UTC-5) can have the effect of going back a day. I have confirmed that I can reproduce on my Mac if I set the timezone to Chicago.
I can’t explain why this only affects the Mac runner, and not the other US-hosted runners. (I’ve checked, and the timestamps in the log are the same as the ubuntu runners which pass fine.)
These are the affected tests:
📦 integration-tests/hibernate-orm-rest-data-panache
✖ io.quarkus.it.hibernate.orm.rest.data.panache.HibernateOrmRestDataPanacheTest.shouldGetAuthor line 51 -
✖ io.quarkus.it.hibernate.orm.rest.data.panache.HibernateOrmRestDataPanacheTest.shouldGetBookHal line 82 -
✖ io.quarkus.it.hibernate.orm.rest.data.panache.HibernateOrmRestDataPanacheTest.shouldGetBook line 70 -
✖ io.quarkus.it.hibernate.orm.rest.data.panache.HibernateOrmRestDataPanacheTest.shouldListAuthors line 97 -
✖ io.quarkus.it.hibernate.orm.rest.data.panache.HibernateOrmRestDataPanacheTest.shouldListBooksHal line 134 -
✖ io.quarkus.it.hibernate.orm.rest.data.panache.HibernateOrmRestDataPanacheTest.shouldListBooks line 109 -
📦 integration-tests/jackson
✖ io.quarkus.it.jackson.DateDeserializerPojoResourceTest.testSqlDate line 41 -
📦 integration-tests/spring-data-rest
✖ io.quarkus.it.spring.data.rest.SpringDataRestTest.shouldGetAuthor line 43 -
✖ io.quarkus.it.spring.data.rest.SpringDataRestTest.shouldGetBookHal line 67 -
✖ io.quarkus.it.spring.data.rest.SpringDataRestTest.shouldGetBook line 55 -
✖ io.quarkus.it.spring.data.rest.SpringDataRestTest.shouldListAuthors line 82 -
✖ io.quarkus.it.spring.data.rest.SpringDataRestTest.shouldListBooksHal line 106 -
✖ io.quarkus.it.spring.data.rest.SpringDataRestTest.shouldListBooks line 94 -
Expected behavior
No response
Actual behavior
No response
How to Reproduce?
To reproduce, I think you will need a Mac? But probably not specifically an M1?
Change the timezone to something West of Greenwich, like a North American or Brazilian time (hi, @gastaldi :) ).
Then
mvn verify -f integration-tests/hibernate-orm-rest-data-panache
will fail.
Output of
uname -a
orver
Darwin hcummins-mac 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
The text was updated successfully, but these errors were encountered: