fix(host): preserve chain-head operation ordering - #310
Conversation
📦 Bundle size impactComparing
Thresholds — 🟡 ≥10% or ≥5.0 KB · 🟠 ≥20% or ≥15.0 KB (bundled). Percentage only applies once the baseline is ≥ 10 KB. Informational — this check never blocks merge. |
valentinfernandez1
left a comment
valentinfernandez1
left a comment
There was a problem hiding this comment.
Just one small comment, you can address it here or on a follow up
|
|
||
| let operation = operations.get(operationId); | ||
| if (!operation) { | ||
| operation = { announced: false, items: [] }; |
There was a problem hiding this comment.
A missing entry here doesn't only mean the Started response hasn't landed. It also means the op already
ended (terminal item at :269, stopOperation at :490, failed start request), and both the spec and PAPI's
cancel path can still emit events after that, so those get buffered and never freed until unfollow.
Suggestion: keep a per-follow counter of start requests still waiting for a response. Only buffer while
that counter is above zero. If it's zero, no Started response can claim this event, so forward it and let
PAPI ignore it like it did before.
2 participants
Problem
TruAPI request responses and follow-subscription events travel on independent frames. A fast chain-head body, call, or storage operation can therefore emit its completion event before the provider publishes the JSON-RPC
Started(operationId)response. PAPI drops that unknown operation event and can wait indefinitely.Changes
Startedresponse has been delivered@parity/product-sdk-hostNo public API or consumer migration is required.
Verification
pnpm --filter @parity/product-sdk-host test -- --run— 106 passedpnpm --filter @parity/product-sdk-host typecheckpnpm exec biome check packages/host/src/papi-provider.tsgit diff --check