fix(genesis-writer): run events before comments - #520
Open
rickyrombo wants to merge 2 commits into
Open
Conversation
The tracks query selected release_date::text, which yields Postgres's own "2026-09-06 22:06:00". The indexer's parseReleaseDate accepts RFC3339, RFC3339Nano and "Mon Jan 02 2006 15:04:05 GMT-0700" -- none of which match -- so releaseDateOrDefault silently fell back to block time, i.e. the source row's created_at. That is not a cosmetic date difference. A track whose release_date lands in the past is then picked up by ScheduledReleasePublisher, which sets is_unlisted = false and updated_at = now(). Measured on the 2026-08-07 snapshot: 372 unlisted tracks with a future release_date had the date rewritten 368 of them were published early 498 -> 136 tracks still holding a future release_date Verified end to end on track 2073330890: source release_date 2026-09-06 22:06:00 and is_unlisted true, the transaction carried both correctly, and the indexed row came out release_date 2025-08-10 20:57:26 (exactly its created_at) with is_unlisted false. Every other timestamp the writer emits already goes out as RFC3339; this one was the outlier.
Comments ran in phase 5 and events in phase 7, so every comment transaction
preceded every event transaction. A comment carrying entity_type=Event is
validated against the state its transaction lands on, and the indexer refuses
it outright with "event %d does not exist".
On the 2026-08-07 snapshot the source holds 69 Event comments. The writer
emitted all of them -- they are on chain as transactions -- and the indexed
database ended up with zero. Row counts on a 327k-row table hid it: 327,916
against 327,835.
The dependency was already understood one line below, for event subscriptions
("the indexer rejects a subscription whose target event does not exist yet").
It was simply never applied to comments.
Extracts the step table into Writer.steps() so the ordering is assertable, and
adds TestStepOrderPutsReferencedEntitiesFirst covering the dependencies that
are not obvious from reading the list. Restoring the old order fails it:
step "events" runs after "comments" (positions 19, 16)
Note this is distinct from the resume truncation that lost 36 events -- a clean
re-run does not fix this one.
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
1 participant
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.
All Event comments are silently dropped
Comments ran in phase 5 and events in phase 7, so every comment transaction preceded every event transaction. A comment carrying
entity_type=Eventis validated against the state its transaction lands on, and the indexer refuses it withevent %d does not exist.Measured on the 2026-08-07 snapshot
The writer emitted all 69 — they are on chain as transactions — and none survived. Row counts on a 327k-row table hid it entirely: 327,916 vs 327,835.
The dependency was already understood one line below, for event subscriptions:
It was simply never applied to comments.
This is not the resume bug
Distinct from the truncation that lost 36 events. A clean re-run does not fix this one — the ordering is wrong regardless.
Test
Extracts the step table into
Writer.steps()so ordering is assertable, and addsTestStepOrderPutsReferencedEntitiesFirstcovering the dependencies that aren't obvious from reading the list. Restoring the old order fails it:🤖 Generated with Claude Code