ChainSafe / ChainSafe/canton-extending-mainnet
[P2-E7.4] getMemberTrafficStatus mispairs sequencer state for dedicated synchronizer ids
- Dominant language
- Shell
- Stars
- 0
- Forks
- 0
- Avg merge
- 22h 58m
- Merged PRs (30d)
- 1
Description
**Context.** `getMemberTrafficStatus(domain_id, member_id)` pairs two data sources that only
agree for the decentralized synchronizer: `actual` (consumed/limit) is read from this SV's own
sequencer, while `domain_id` is a path parameter (`HttpScanHandler.scala:2310-2321` on
`feat/dedicated-sync`). Query it with a dedicated synchronizer id and it returns the
decentralized sequencer's actual state paired with the dedicated synchronizer's purchase total:
HTTP 200, plausible-looking, wrong. Found while auditing migration-id handling for #83.
**Deliverable.** Either gate the endpoint (reject synchronizer ids the serving sequencer does not
serve, an explicit error instead of a bogus 200) or supersede it for dedicated synchronizers via
the P2-E7.2 endpoints (#42), which already plan funding-side totals without a consumed field.
Decide, implement the guard, and note the decision on #42 so the two do not drift.
**Acceptance.** Querying traffic status for a dedicated synchronizer id against a decentralized
Scan yields an explicit error or a documented redirect to the per-synchronizer endpoints; an
integration or handler test pins it.
**Depends on.** Coordinates with #42 (P2-E7.2). Independent of the #83 ingestion fix (the
mispairing exists regardless).
**Note.** `CachingScanStore` memoizes `getTotalPurchasedMemberTraffic` per (member, synchronizer)
with a TTL (`CachingScanStore.scala:133-139`, TTL at `ScanAppConfig.scala:174`), so zeros cached
before the #83 ingestion fix deploys linger for one TTL window after it. Transient by design;
called out here so nobody debugs it as a fix regression.
—
Epic: #70 · Plan: [P2-E7-scan.md](https://github.com/ChainSafe/canton-extending-mainnet/blob/main/docs/planning/phase-2-epics/P2-E7-scan.md)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in HttpScanHandler.scala:2310-2321 and compare getMemberTrafficStatus with the per-synchronizer endpoints planned in #42. Decide whether to reject unsupported synchronizer ids or redirect dedicated synchronizers, then coordinate the decision on #42. Add an integration or handler test showing that a dedicated id queried against a decentralized Scan returns an explicit error or documented redirect.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100