Repository navigation
MPDX-10133 Stop error link crash that left pages stuck loading - #2127
Conversation
Bundle sizes [mpdx-react]Compared against 06ca668 No significant changes found |
|
🤖 agent-review · ✅ no blockers · risk CRITICAL BLOCKERS — fix or dismiss to pass✅ No blockers. OTHER FINDINGS (5)
🔧 Fix suggestions (3)
- {loadError ? (
+ {isHcmUnavailableError(hcmError) ? (
+ <HcmUnavailableAlert refetch={refetchHcm} />
+ ) : loadError ? (
+ expect(snackNotifications.error).toHaveBeenCalledTimes(1);No fix scripts were generated; apply by hand. 📦 Dependency impactBlast radius: 138 files (not truncated).
The large blast radius comes from 📊 Review detail & statsGenerated: 2026-10-07 · Day: Wednesday · Files changed: 7 (+362 -178 lines) Risk factors detected: core infrastructure scope (×2 multiplier) on both Apollo error links ( Deterministic evidence:
Agent summary (bands: Critical 9-10 · High 7-8 · Important 5-6 · Suggestions 3-4):
Per-agent perspectives on blockers: none (no blockers). Open question raised by agents:
Review quality:
💬 How to act on this reviewEvery finding above is numbered. Severity ≥ 7 findings carry a checkbox and must each be fixed or
Or locally: |
Apollo passes a failed response's `errors` to the error link unchecked. When it was an object or string, `graphQLErrors.forEach` threw inside Apollo's error callback, so the error never reached the query and pages like the Staff Expense Report stayed on their loading skeletons. The link now only walks `graphQLErrors` when it is an array; network errors are still toasted and reported. The Staff Expense Report also treats a failed Hcm query as a load error: it shows the existing alert instead of loading the report with the wrong fund types and no salary split, and Try Again refetches Hcm. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
9e9cdff to
5c2422f
Compare
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The server-side error link had the same problem as the browser one: Apollo passes a failed response's `errors` through unchecked, and calling `.map` on an object or string threw inside the link, so the query never settled and getServerSideProps hung. Only walk the errors when they are an array; the network error is still sent to Rollbar. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5c2422f to
9b409f1
Compare
Description
MPDX-10133. Related backend fix: MPDX-10132 (CruGlobal/mpdx_api#3678).
graphQLErrors.forEach is not a functionwhen a failed response'serrorswas an object or string instead of an array. Apollo passes that value through unchecked, and because the throw happens inside its error callback, the error never reached the query, so it stayed loading forever (the Staff Expense Report skeletons in HS-1776512).graphQLErrorswhen it is an array. Network errors are still shown in the snackbar and reported to Datadog as before.Note: the API's own 500 for
/graphqlreturnserrorsas an array, which was already handled. The Datadog issue was first seen on 8/24, before the Hcm 500s started on 10/5, so something else is sending the non-array shape. This change handles any shape, but the source is still unknown.Testing
client.test.tscovers object, string and arrayerrorson a network error;StaffExpenseReport.test.tsxcovers the Hcm failure alert and Try Again recovery.Checklist:
/quality:agent-reviewcommand locally and fixed any relevant suggestions🤖 Generated with Claude Code