-
-
Notifications
You must be signed in to change notification settings - Fork 597
fix(core): fix same-second dates diffing #6094
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
Conversation
I reverted the test changes made in 55df57f, the CI should pass now |
healthcheck: | ||
test: /opt/mssql-tools/bin/sqlcmd -S mssql -U sa -P 'Root.Root' -Q 'select 1' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@boenrobot looks like this solves the flaky CI runs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm or maybe not :D but it feels better, lets see
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, spoke too soon, judging by the latest commit results in master. But I'm sure this does help reduce the flaky-ness.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #6094 +/- ##
=======================================
Coverage 99.79% 99.79%
=======================================
Files 264 264
Lines 18756 18757 +1
Branches 4090 4090
=======================================
+ Hits 18717 18718 +1
Misses 39 39 ☔ View full report in Codecov by Sentry. |
This PR fixes an issue I introduced in #6094 Using `toISOString()` on an invalid date throws a [RangeError exception](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString#exceptions). We should test if the date is valid before comparing it with `toISOString()`.
This small PR fixes a minor regression that I think was introduced in 55df57f.
Issue
When updating an entity and changing a date property to another one very close to it (by a difference in microseconds), the change is not persisted in the database. Indeed, diffing dates by comparing the
toString()
output doesn't give enough precision to compare microseconds shifts. Example:toString()
output:Tue Oct 01 2024 08:54:48 GMT+0000 (Coordinated Universal Time)
toISOString()
output:2024-10-01T08:54:48.651Z
Two dates can have the same
toString()
output even though theirtoISOString()
output is different.The impact is low and probably only concerns the test scenarios: It's rare to persist the same entity twice in the same second without changing anything other than a date.
Fix
In this PR I'm switching the dates comparison to use
toISOString()
and adding a new unit test.