ChainSafe / ChainSafe/canton-extending-mainnet

[P2-E7.4] getMemberTrafficStatus mispairs sequencer state for dedicated synchronizer ids

Open
#108 1 comment 0 reactions 0 assignees View on GitHub
phase-2
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.