fix(navigation): swallow 403 on boot-time proxy_records fetch - #68387
Conversation
projectNoticeLogic.loadRecords fires GET proxy_records on every scene for every logged-in user. A restricted org member whose access level to the org resource is below read gets a 403 from the RBAC layer. The catch block only swallowed 401 and re-threw everything else, so the 403 leaked into error tracking as an uncaught "Non-OK response" error. Extend the existing guard to also swallow 403 (return null) since there's no banner to show that member anyway. Generated-By: PostHog Code Task-Id: d19a3c2e-65d9-4e33-a161-7b81b2681837
posthog
Bot
added
the
skip-agent-review
🤖 CI report
|
| Root | Eager (shipped) | Δ vs base | Budget |
|---|---|---|---|
entry (logged-out pages, app bootstrap)src/index.tsx |
1.24 MiB · 22 files | no change | ███░░░░░░░ 27.6% of 4.51 MiB |
authenticated shell (every logged-in page)src/scenes/AuthenticatedShell.tsx |
8.09 MiB · 3,014 files | 🔺 +18 B (+0.0%) | ████████░░ 83.3% of 9.71 MiB |
🟢 node_modules/monaco-editor/ stays out of src/index.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/index.tsx
🟢 [object Object] stays out of src/index.tsx
🟢 [object Object] stays out of src/index.tsx
🟢 node_modules/monaco-editor/ stays out of src/scenes/AuthenticatedShell.tsx
🟢 src/lib/components/ActivityLog/describers stays out of src/scenes/AuthenticatedShell.tsx
🟢 [object Object] stays out of src/scenes/AuthenticatedShell.tsx
🟢 [object Object] stays out of src/scenes/AuthenticatedShell.tsx
Largest files eagerly shipped from src/index.tsx
| Size | File |
|---|---|
| 126.8 KiB | ../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js |
| 24.6 KiB | ../node_modules/.pnpm/buffer@6.0.3/node_modules/buffer/index.js |
| 6.3 KiB | ../node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react.production.min.js |
| 4.5 KiB | ../node_modules/.pnpm/@jspm+core@2.1.0/node_modules/@jspm/core/nodelibs/browser/process.js |
| 3.9 KiB | ../node_modules/.pnpm/scheduler@0.23.2/node_modules/scheduler/cjs/scheduler.production.min.js |
| 1.4 KiB | ../node_modules/.pnpm/base64-js@1.5.1/node_modules/base64-js/index.js |
| 1.3 KiB | src/RootErrorBoundary.tsx |
| 912 B | ../node_modules/.pnpm/ieee754@1.2.1/node_modules/ieee754/index.js |
| 789 B | src/scenes/ChunkLoadErrorBoundary.tsx |
| 762 B | src/index.tsx |
Largest files eagerly shipped from src/scenes/AuthenticatedShell.tsx
| Size | File |
|---|---|
| 281.6 KiB | ../node_modules/.pnpm/posthog-js@1.407.5/node_modules/posthog-js/dist/rrweb.js |
| 267.7 KiB | ../node_modules/.pnpm/@posthog+icons@0.38.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js |
| 235.5 KiB | src/taxonomy/core-filter-definitions-by-group.json |
| 226.5 KiB | ../node_modules/.pnpm/posthog-js@1.407.5/node_modules/posthog-js/dist/module.js |
| 154.3 KiB | ../node_modules/.pnpm/re2js@0.4.1/node_modules/re2js/build/index.esm.js |
| 126.8 KiB | ../node_modules/.pnpm/react-dom@18.3.1_react@18.3.1/node_modules/react-dom/cjs/react-dom.production.min.js |
| 105.2 KiB | src/lib/api.ts |
| 94.0 KiB | ../packages/quill/packages/quill/dist/index.js |
| 93.3 KiB | ../node_modules/.pnpm/prosemirror-view@1.40.1/node_modules/prosemirror-view/dist/index.js |
| 90.6 KiB | ../node_modules/.pnpm/@tiptap+core@3.20.6_@tiptap+pm@3.20.6/node_modules/@tiptap/core/dist/index.js |
Posted automatically by check-eager-graph · sizes are eager output bytes (shipped, post-tree-shake) from the esbuild metafile · part of #32479
✅ Toolbar bundle — eager 2.18 MiB within budget
What the toolbar ships to customer pages, measured from the esbuild output (minified, post-tree-shake). The eager set is the entry plus everything statically imported from it — fetched before any feature runs; deferred chunks load lazily. The eager guardrail is 5.72 MiB. Each output file must also stay below 10 MB, where CloudFront stops compressing it. The module boundary is enforced separately by check-toolbar-graph.
| Metric | Size | Δ vs base | Budget |
|---|---|---|---|
| Eager (shipped) entry + static imports |
2.18 MiB · 17 files | no change | ████░░░░░░ 38.2% of 5.72 MiB |
| Deferred (lazy) | 2.07 MiB · 33 files | no change | n/a — loads on demand |
Loader dist/toolbar.js |
1.1 KiB | no change | █░░░░░░░░░ 5.8% of 19.5 KiB |
Largest eagerly-shipped chunks
| Size | File |
|---|---|
| 716.9 KiB | dist/toolbar/toolbar-app-5ZPNOWI2.css |
| 546.0 KiB | dist/toolbar/chunk-chunk-RYIMUIPJ.js |
| 484.3 KiB | dist/toolbar/chunk-chunk-H6BYZJQ3.js |
| 133.6 KiB | dist/toolbar/chunk-chunk-XBQFUAE7.js |
| 131.8 KiB | dist/toolbar/chunk-chunk-T5KY5WYR.js |
| 71.0 KiB | dist/toolbar/toolbar-app-CDD54Z26.js |
| 69.0 KiB | dist/toolbar/chunk-chunk-27JL52RE.js |
| 35.6 KiB | dist/toolbar/chunk-chunk-Q3YINSLU.js |
| 20.9 KiB | dist/toolbar/chunk-chunk-4HWCX3DX.js |
| 12.2 KiB | dist/toolbar/chunk-chunk-PIK3PADE.js |
Posted automatically by check-toolbar-size · sizes are toolbar output bytes (shipped, post-tree-shake) from the esbuild metafile
✅ Dist folder size — 🔺 +180 B (+0.0%)
Total size of the built frontend/dist folder (all assets), compared against the base branch.
Total: 1360.48 MiB · 🔺 +180 B (+0.0%)
|
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, please remove the |
|
👋 Visual changes detected for this PR. Review and approve in PostHog Visual Review If these changes are unexpected, they may be caused by a flaky test or a broken snapshot on master. Don't approve — rerun the job or wait for a fix. |
|
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, please remove the |
1 participant
Problem
projectNoticeLogicis mounted in the authenticated navigation shell, so on every scene it firesloadRecords, which doesGET /api/organizations/:id/proxy_records/for every logged-in user. That endpoint runs through the RBAC access-control layer, which returns a 403 for a member whose access level to the org resource is below read. The loader's catch block only swallowed 401 and re-threw everything else, so the 403 propagated out and got captured in error tracking as an uncaught "Non-OK response" error.There's no user-facing breakage - the reverse-proxy notice just doesn't render for that member - so the only cost is noise in the error stream, plus the risk it recurs as org access-control restrictions spread.
Changes
Extend the existing 401 handling in
projectNoticeLogic.loadRecordsto also swallow 403 (return null) instead of re-throwing, mirroring the pattern already there. There's no banner to show that member either way.How did you test this code?
I (Claude) parameterized the existing "proxy records 401 handling" test to cover both 401 and 403, asserting the loader dispatches
loadRecordsSuccess(notloadRecordsFailure) and leavesproxyRecordsnull. This catches the regression the fix targets: before, a 403 re-threw and surfaced as a load failure.Note: this environment had no installed node toolchain, so I could not run jest or the linters locally. The change is a one-line extension of an already-tested pattern.
Automatic notifications
Docs update
No docs affected.
🤖 Agent context
Autonomy: Fully autonomous
Authored by Claude Code from an inbox report flagging an uncaught 403 leaking into error tracking from the boot-time
proxy_recordsGET. The fix is confined to theloadRecordscatch block inprojectNoticeLogic.tsx; I traced the 403 to the RBACAccessControlPermissionlayer on the organization-scopedProxyRecordViewsetand confirmed the loader only handled 401. No skills were required for this pure.tsx/test change.Created with PostHog Code from an inbox report.