CedarCopilot wants to merge 3 commits into staging from fix/inbox-partial-channel-failure
Live on prod, no production signal yet
Verification reached its 130s outer budget before the verifier returned. Libra is keeping this intent verifying until the next check.
Verification reached its 120s wall-clock budget before a tied verdict. Libra is keeping this intent verifying until the next check.
Verification reached its 130s outer budget before the verifier returned. Libra is keeping this intent verifying until the next check.
Verification reached its 120s wall-clock budget before a tied verdict. Libra is keeping this intent verifying until the next check.
Libra has verdicts on 0 of 6 tracked behaviors on prod; 6 are still being checked. Libra checks hourly for 3 days after each deploy.
Fixes the two P1s Greptile raised on #2641, which merged before they were addressed.
The unified feed is one query per channel, so Slack can fail while email and LinkedIn are perfectly healthy. Two separate things turned that into a blank screen.
A failed channel never became settled. settled was data !== undefined, and a rejected query has no data. The merge refuses to render until every channel settles , correctly, since an unsettled channel could still return an item of any timestamp, so no prefix is provably stable. So ready stayed false, isLoading stayed true, and InboxList (which checks loading before error) spun forever. Not "Slack is down" , an indefinite spinner.
A failed channel is now settled-and-empty, which is exactly how the merge already treats a channel that came back empty: it contributes nothing and bounds nothing.
isError was some(channel => channel.isError), which blanks a working list and throws away every row the healthy channels did return. The feed now errors only when it genuinely cannot answer , the scope query failed (we don't even know which channels participate), or every participating channel failed. The channels that did fail are named in failedChannels, and the list reports them inline above the rows it can still show, with a retry.
A channel that is merely slow still gates the merge. Only a terminal failure settles early, because a pending channel really can still return anything , that distinction has its own test.
headChangedmail.listThreads reconciles page-1 freshness inline and sets headChanged when the reconcile shifted the head. The unified feed asks as surface: 'unified-feed' so the server's latch hands it its own copy rather than letting the email list swallow it , but nothing here consumed it. After a head shift, cached page-2+ cursors minted against the old boundary kept being replayed across it.
Now funnels through the same resetListThreadsToFirstPage the email list uses, on the false→true transition only (the inline reconcile is idempotent, so the refetch returns headChanged: false and this converges instead of looping).
Flattening also dedupes by thread id , the same safety net useThreads keeps over the same pages. The reset removes the cause of an overlap but lands a render later, and a row appearing twice for a frame is precisely the artifact the watermark exists to make impossible.
tests/modules/inbox/feedPartialFailure.test.tsx , 8 cases. Mutation-tested: 6 fail against the previous behavior, and the 2 that pass either way are the deliberate controls (a slow channel still gates; a steady head fires nothing).
tsc -b --force cleanOne line added to feedScopeGate's react-query mock: the email source now reads the query client, and that suite renders no provider.
🤖 Generated with Claude Code
The PR makes the unified inbox tolerate individual channel failures, reports degraded channels inline, and resets email pagination after a reconciled head shift.
headChanged signal.The PR should not merge until failed refetches stop contributing retained data and head-change resets are tracked per email query.
A background channel failure can leave stale rows participating in the merge, while a query switch during consecutive head-change signals can preserve later pages built against an obsolete boundary.
*Files Needing Attention:
Libra has not measured any production surfaces for this change yet.