Send the faded order hashes that caused a circuit breaker block in the blocking notification

[claude]

Requested by Christian Angelopoulos · Slack thread

Before / After

Before: when the circuit breaker blocks a filler, the blocking notification POSTed to their endpoint contains only { blockUntilTimestamp } — fillers cannot tell which order(s) triggered the block.

After: the notification names the faded order(s) that caused the block — the hashes of the posted orders the filler faded, which is what fired the circuit breaker in the first place. This works for both soft- and hard-quote requests, since the cause of a block is always a posted order:

{
  "blockUntilTimestamp": 1783970000,
  "orderHashes": ["0x9f2b...c41a", "0x77aa...01ce"],
  "quoteId": "b71e2a10-..." // current request's quoteId, when it carries one (hard quotes)
}

requestId is no longer sent. Block entries written before this change have no stored hashes; for those, orderHashes is simply omitted during the transition (entries refresh on every cron run, so this window is short).

How

The fade-rate-v2 cron is the block writer: it queries the latestRfqsV2 Redshift view for each filler's recent orders and whether each faded, computes per-filler Laplace-smoothed fade rates, and writes the block entry per filler to the Dynamo timestamps table. This change threads the faded orders' hashes along that same path (kept current with #454's rate-based trigger, #465/#473's cleanups, and #482's clean-run decay streak via merges):

• lib/repositories/fades-repository.ts: the latestRfqsV2 view and V2_FADE_RATE_SQL now also select orderHash (column verified against posted_orders.yaml in data-eng-workflows, where it is also a dedupe key — present on every row); V2FadesRowType gains orderHash.
• lib/cron/fade-rate-v2.ts: getFillersFadeStats() now also collects the faded orders' hashes per cohort (windowFadedOrderHashes for the post-block rate window, duringBlockFadedOrderHashes for the in-flight-during-block cohort). calculateNewTimestamps() persists on the block entry the hashes of whichever cohort(s) tripped or extended the block: set on a new block, appended (deduped, capped at MAX_FADED_ORDER_HASHES = 50, most recent kept) on extension, carried forward while the block is active, and cleared when the filler drops back under threshold.
• lib/repositories/base.ts + lib/repositories/timestamp-repository.ts + lib/constants.ts: additive optional fadedOrderHashes list attribute on the timestamp row — written only when present, read back as undefined on legacy rows, no changes to existing attributes.
• lib/providers/circuit-breaker/{index,dynamo,mock}.ts: EndpointStatuses.disabled entries surface fadedOrderHashes.
• lib/quoters/WebhookQuoter.ts: notifyBlock() sends orderHashes from the block entry (omitted when the entry has none) plus the current request's quoteId when present; requestId removed.
• lib/entities/{QuoteRequest,HardQuoteRequest}.ts: unchanged from main — the earlier threading of the current request's order hash is no longer needed.

Testing

• jest unit suite on the merged result (base acce427): 31 suites passed, 300 tests passed. New coverage: per-cohort faded-hash collection in the cron, block/extend/carry-forward/clear/cap persistence semantics, Dynamo round-trip incl. legacy rows without the attribute, provider propagation, and exact notification payloads incl. the legacy-entry case.
• tsc build clean; touched files pass prettier --check and eslint with no errors and no new warning patterns.

Context: reported by a filler (Thomas Retraint) — blocked fillers receive the notification but cannot identify the order that triggered the circuit breaker.