Skip to content

Fix ANS v2 current-row Ord omitting token_standard from PK - #63

Open
sausagee wants to merge 3 commits into
mainfrom
cursor/fix-ans-v2-ord-pk-0bac
Open

Fix ANS v2 current-row Ord omitting token_standard from PK#63
sausagee wants to merge 3 commits into
mainfrom
cursor/fix-ans-v2-ord-pk-0bac

Conversation

@sausagee

@sausagee sausagee commented Sep 6, 2026

Copy link
Copy Markdown

Bug

CurrentAnsLookupV2 and CurrentAnsPrimaryNameV2 derive PartialEq/Eq over all fields (including token_standard) but their custom Ord implementations compared only a prefix of the Postgres primary key.

Schema PKs:

  • current_ans_lookup_v2 (domain, subdomain, token_standard)
  • current_ans_primary_name_v2 (registered_address, token_standard)

token_standard is in the PK so v1-migrated and native v2 rows can coexist. pk() already includes it for in-memory dedup. Ord did not.

Root cause

v1 and v2 rows for the same name/address are not PartialEq equal, yet Ord::cmp returned Equal. parse_ans in ans_extractor.rs sorts these maps before upsert specifically to avoid Postgres deadlocks during parallel chunked writes (execute_in_chunks in ans_storer.rs). Distinct PK tuples that compare equal have undefined relative order after .sort() (HashMap iteration), so two workers can lock (domain, subdomain, v1) vs (domain, subdomain, v2) (or the primary-name equivalent) in opposite orders and deadlock.

This is not the intentional ANS domains rename, and it is not covered by PRs #16#62.

Fix

Extend both Ord implementations to match the schema PK (+ token_standard). No domain/subdomain rename, no ANS table-shape change.

Tests

Verified locally (rustc 1.85.0):

cargo test -p processor --lib ord_includes_token_standard_in_pk
  • processors::ans::models::ans_lookup_v2::tests::ord_includes_token_standard_in_pk — ok
  • processors::ans::models::ans_primary_name_v2::tests::ord_includes_token_standard_in_pk — ok
cargo clippy -p processor --lib

Finished cleanly.

Open in Web Open in Cursor 

CurrentAnsLookupV2 and CurrentAnsPrimaryNameV2 derive Eq over all fields
(including token_standard) but Ord compared only the PK prefix. v1 and v2
rows for the same name/address compared Equal despite not being Eq-equal,
so extractor .sort() left their order undefined and parallel upserts could
deadlock on distinct PK tuples.

Co-authored-by: Young Yang Liauw <sausagee@users.noreply.github.com>
@sausagee
sausagee marked this pull request as ready for review September 6, 2026 16:24
@sausagee
sausagee changed the base branch from main to fix/lint-stable-xclippy September 7, 2026 22:19
@sausagee
sausagee changed the base branch from fix/lint-stable-xclippy to main September 7, 2026 22:31
Stack the CI unblocker files from PR #70 (stable cargo xclippy, bookworm Dockerfiles with make) onto this bugfix branch so CI can go green while #70 awaits review. Merge target remains main; this does not merge #70.
CI Lint: apply cargo +nightly fmt so rustfmt --check passes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants