- Shipped
- 20 Agosti 2026, 01:57 UTC
- Author
- Kamo
- Commit
- cd461c2
Both paged queries ordered on a column that ties, with no tiebreaker, so the database was free to return tied rows in a different order per page fetch — which shows the reader one row twice and hides another. It is not a rare tie either: OCCURRED_AT is @CreationTimestamp(source = DB), i.e. current_timestamp, which on Postgres/YSQL is the TRANSACTION start time, so every event written in one transaction carries a byte-identical stamp. Both now break ties on the id. The visitor list also ordered DESC on the nullable LAST_SEEN_AT, and Postgres sorts NULLS FIRST on DESC, so a visitor row that had not been bumped yet would pin itself to the top of "recent visitors" permanently. Written out as an explicit query because NULLS LAST cannot be expressed in a derived method name. findByUserId and findByCreatedOrganizationId become **************** Nothing enforces one visitor row per account — clearing cookies and returning on another code legitimately makes a second — so an Optional-returning finder would throw **************** on the conversion path rather than return a row. Earliest wins, matching the first-touch model. Also corrects **************** javadoc, which called itself the reconcile ground truth while counting events of every type; rebuilding PAGE_REQUESTS from it would overstate a converted visitor by up to three, and the reconcile SETs rather than adds. The job already uses the right source — only the comment invited the mistake.