Skip to content

instruments: use API-prefixed builder-dex names verbatim, no double-prefix#9

Open
armcconnell wants to merge 1 commit into
mainfrom
pr/builder-dex-double-prefix
Open

instruments: use API-prefixed builder-dex names verbatim, no double-prefix#9
armcconnell wants to merge 1 commit into
mainfrom
pr/builder-dex-double-prefix

Conversation

@armcconnell
Copy link
Copy Markdown
Collaborator

Summary

The HL `info` endpoint's `meta {dex: }` call returns asset `name` already prefixed with the dex (e.g. `"xyz:XYZ100"`, `"cash:USA500"`). hl-node also writes those same prefixed names into the streaming/by-block files. So the registry's coin key MUST equal the wire name verbatim.

The current `parse_builder_dex_asset` does `coin = format!("{dex}:{name}")` after reading the already-prefixed `name`, producing the doubly-prefixed key `"xyz:xyz:XYZ100"`. The DoB tap and TOB publish-paths then fail to resolve every event for every builder-dex coin, dropping them all from both feeds. The publisher logs ~584 `dob_tap: unknown coin` warns/sec on a live HL mainnet node — every single builder-dex order add/cancel/execute, silently lost.

This PR uses the API name verbatim, but defensively re-prefixes only when the name doesn't already start with `:`. That keeps the registry key correct under the current API and survives a hypothetical future API change to unprefixed names.

Impact (measured on aws-tyo-hl-mainnet, 2026-05-08)

Pre-fix Post-fix
`dob_tap: unknown coin` warn rate 583/sec 24/sec
Distinct unknown coins 7 dex prefixes + numeric numeric `#NNN` only (separate issue)
DoB mktdata pkts/sec on 233.84.178.6:10001 ~205 ~573

Verified across all seven configured DEXes on mainnet (`xyz`, `cash`, `hyna`, `km`, `flx`, `vntl`, `para`) — every `meta {dex}` response uses the prefixed-name shape. The `xyz` dex alone is 77% of the previously-lost volume (real-world equities, commodities, FX, indices).

Tests

  • `parse_builder_dex_asset_uses_api_prefixed_name_verbatim` (new) — pins the new invariant against the real API shape; would fail on the doubly-prefixed key.
  • `parse_builder_dex_asset_prefixes_unprefixed_name_defensively` (new) — covers the defensive branch.
  • `parse_builder_dex_asset_prefixes_coin` and `parse_builder_dex_asset_delisted` (existing) — unchanged input shape, exercise the defensive prefix branch and continue to pass.

`cargo test --workspace`: 124 passed, 0 failed.

…refix

The HL `meta {dex}` endpoint returns asset `name` already prefixed with
the dex (e.g. `"xyz:XYZ100"`, `"cash:USA500"`). hl-node also writes
those same prefixed names into the streaming/by-block files. So the
registry's coin key MUST equal the wire name verbatim.

The current code was constructing `coin = format!("{dex}:{name}")` after
reading `name = "xyz:XYZ100"` from the API, producing the doubly-prefixed
key `"xyz:xyz:XYZ100"`. The DoB tap and TOB publish paths then failed to
resolve every event for every builder-dex coin, dropping them all from
both feeds. ~584 unknown-coin warns/sec on aws-tyo-hl-mainnet across all
seven configured DEXes (xyz, cash, hyna, km, flx, vntl, para) — 172
distinct coins missing.

The xyz dex alone accounts for 77% of the unknown-coin volume (real-world
equities, commodities, FX, indices) — the data subscribers most want.

Fix: prefer the API name verbatim, but defensively prefix only when the
name doesn't already start with `<dex>:`. That keeps the registry key
correct under the current API and survives a hypothetical future API
change to unprefixed names.

New tests:
  - parse_builder_dex_asset_uses_api_prefixed_name_verbatim — asserts
    the new invariant against the real API shape (`name: "xyz:XYZ100"`).
  - parse_builder_dex_asset_prefixes_unprefixed_name_defensively —
    keeps the old behavior available for an unprefixed name.

The pre-existing `parse_builder_dex_asset_prefixes_coin` and
`_delisted` tests still pass: they were written against the old
unprefixed assumption and now exercise the defensive branch.

cargo test --workspace: 138 passed, 0 failed.
@armcconnell armcconnell requested a review from packethog May 14, 2026 15:33
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.

1 participant