Repository navigation
fix(tests): replay go-gdpr's recorded first sync on a fixed clock - #29
Merged
Merged
Conversation
record_first_sync ran the replayed sync on the system clock. The sync's 24-hour account refresh measures each account from its recorded Date header (2026-10-20 23:36 UTC for the go-gdpr recordings), so from a day after the recording the replay asked for user lookups the recording does not hold, the replay answered 418, and five tests in tests/source/test_recorder.py failed on every run. record_first_sync takes a clock, as record does, and uses it for the source and the engine; a live recording keeps the system clock, and every replayed call in the tests passes FakeClock.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Five tests in
tests/source/test_recorder.pyfail on every run since 2026-10-21 23:36 UTC, onmainand on every pull request:test_recording_a_first_sync_of_its_recordings_gives_them_backtest_a_retried_item_records_one_unit_per_file[first sync]test_a_first_sync_that_does_not_exit_0_stops_the_recordingtest_only_first_sync_writes_its_directory_alone[False]and[True]Each fails with
UnexpectedResponse: GitHub answered 418: no user unit for {'id': ...}.Cause
record_first_sync(tests/source/recorder.py) ran its sync onSystemClock(). The tests replay go-gdpr's recorded first sync (tests/fixtures/source/first_sync/, recorded 2026-10-20 23:36 UTC). The sync's 24-hour account refresh (REFRESH_AFTER,sync/writer.py) measures each account from its recordedDateheader. So once a day had passed, the replayed run looked up accounts the recording does not hold, and the replay answered 418.tests/sync/test_first_sync.pyreplays the same recordings onFakeClockand is unaffected.Change
record_first_synctakesclock, asrecorddoes, and uses it for both the source and the engine. A live recording (scripts/record_fixtures.py --only first-sync) keeps the system clock.tests/source/test_recorder.pypassesFakeClock(), which starts at 2026-10-17 12:00 UTC, before the recordings.test_recording_a_first_sync_of_its_recordings_gives_them_backalready asserts the replay asks for exactly Resolve, PullRequestIndex, PullRequestBatch, and one UserLookup, so a refresh lookup fails it.No code under
src/,scripts/, oralembic/changes.Head:
f79e239b2c5baa1c5220119cedd1ff34a85bf362Ran:
uv run --no-sync pytest tests/source/test_recorder.pyonmain's code: the five tests above fail.main'stests/source/recorder.py: they fail withTypeError: record_first_sync() got an unexpected keyword argument 'clock'.uv run --no-sync pytest(full suite): 2058 tests, 0 failures, 0 errors, 0 skipped (JUnit report), andscripts/check_junit.py --max-skipped 0passes.uv run --no-sync pre-commit run --all-files: passed.Not run: a live recording (
scripts/record_fixtures.py --only first-sync).