[Makisuo]

Part 3 of 3: the ingest keys UI, rebuilt after the Paper design. Base: #1519.

Settings → Ingestion splits into Setup, Keys and Attribute mappings.

• Keys is one table with the default and custom keys:
  • status (live, idle, no data yet, paused, expired);
  • signals, rate limit, overrides and last data;
  • a filter.
    Rows open from the mouse or the keyboard.
• New key and Configure are a full page in sections: basics, signals, limits, resource attributes. A live preview shows how each attribute lands on a sample sender ("production → staging, overwritten" or "kept, sender set it").
• A key's page shows:
  • after create or roll, the one-time secret with paste-ready Environment / OTel Collector / Browser SDK snippets. It is held in memory only and dropped once you leave the page.
  • status cards: receiving data, last 24h spans and logs, config changed;
  • a 24h volume chart;
  • the configuration;
  • actions: Configure, View traces, Pause (1 hour / 24 hours / until I resume) or Resume, Roll secret, Delete.
• The authentication docs cover pause and usage.

Keys	New key

Limits and attribute preview	Key created (one-time secret)

Live key	Pause menu

Paused, with stored volume	Paused (dark)

Verified in the local dev stack, signed in, against the real API, Postgres and warehouse:

• create, configure, pause, resume, roll and delete;
• the paused state flowing into the gateway, as shown in feat(ingest): enforce custom ingest keys in the gateway #1519;
• the volume chart reading spans stored with a key in an earlier session.

Browser tests:

• the form: attribute preview, reserved key blocked, payload and secret handoff;
• the key page: each pause choice sends the right until, Resume on a paused key, and a rolled secret handed up.

Both tests were mutation-checked. Web typecheck and oxlint are clean.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 05e4639f-704b-4a0f-83c7-30a7e10306d1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[maple-review-bot]

Maple review

🟢 Confidence 8/10 · likely safe to merge
Contained settings UI over the base branch's v2 endpoints; I verified the wire field names, the signal union and the ConfirmDialog promise contract, and the new logic is otherwise self-consistent.
_{quality 100/100 · no findings · tests missing · risk medium · 1/1 new units observable}

Adds a Custom keys section to Settings → Ingestion that lists, creates, edits, enables, rolls and deletes custom ingest keys, plus a new list atom and an authentication-docs section. The API contracts it calls all exist and no defect turned up; safe to merge, with no browser test covering the new section.

• CustomIngestKeysSection manages custom ingest keys against /v2/ingest_keys/custom with a one-time secret dialog
• customIngestKeysListAtom pages the full custom-key list via collectV2Pages
• The edit dialog can keep, clear or replace a key's expiry

Production impact

Production traffic of the changed files (last 7 days)

File	Calls/day	Busiest operations
apps/web/src/components/settings/custom-ingest-keys-section.tsx	1.3M	POST /v1/traces 459k/day, 0.0% err POST /v1/traces 314k/day, 0.0% err POST /v1/metrics 188k/day, 0.0% err

What was checked

• Wire field names match the v2 schemas: expires_at ISO string, rate_limit_rps, allowed_signals, key_prefix
• SIGNALS mirrors the five IngestKeySignal members, so selecting all five and sending null cannot grant an unseen signal
• Delete reuses ConfirmDialog's promise contract: true closes, false keeps it open after the toast (confirm-dialog.tsx:67)

Observability coverage: 1 of 1 changes observable

Change	Kind	Observable	Evidence
Custom ingest key list/create/update/roll/delete calls to /v2/ingest_keys/custom	client	yes	Goes through MapleApiV2AtomClient/MapleFetchHttpClientLive like the mappings and recommendations atoms; the server side emits the request span

_{d169dbc · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[github-actions]

🍁 Maple PR preview

Warning

Preview cleanup could not be confirmed. The Alchemy teardown outcome was failure.

Final commit 8546136 · View workflow run

[maple-review-bot]

Maple review

🟢 Confidence 7/10 · likely safe to merge
Every hunk of the new section and the helpers it relies on were read; only the new form validation and reveal flow have no test.
_{quality 98/100 · 1 note · tests missing · risk medium · 0/1 new units observable}

Adds a Custom keys section to Settings → Ingestion that lists and manages custom ingest keys (create, edit, enable/disable, roll, delete) against /v2/ingest_keys/custom, showing the one-time secret masked after create and roll. UI-only, no server contract change; safe to merge once the base branch lands.

• New CustomIngestKeysSection lists, creates, edits, rolls and deletes custom ingest keys
• One-time secret shown masked with reveal/copy after create and roll
• customIngestKeysListAtom paginates /v2/ingest_keys/custom for the settings page
• Edit dialog can keep, clear or change the stored expiry

Before merge

• Manual · Land the base branch (feat(ingest): enforce custom ingest keys in the gateway #1519) first: /v2/ingest_keys/custom and the gateway's custom-key lookup come from it

Findings

🔵 Note · F1 · Custom-key form rules and create→reveal flow have no test

tests · apps/web/src/components/settings/custom-ingest-keys-section.tsx:168-174

This section adds rules the server enforces with a 400 (rate-limit bounds, reserved org_id/maple_* keys, duplicate or valueless attribute rows) and a one-time secret that is only ever returned by create and roll, and none of it is exercised by a test, while the sibling roll-api-key-dialog.browser.test.tsx pins exactly that secret-survival property for API keys. A regression in formValid or a dropped reveal would ship unnoticed.

Add `custom-ingest-keys-section.browser.test.tsx` along the lines of `roll-api-key-dialog.browser.test.tsx`: mock `useAtomSet` in `@/lib/effect-atom`, then assert that an attribute row with a reserved key or a duplicate disables submit, and that a successful create renders the returned `secret` in the reveal dialog.

🤖 Prompt to fix this finding with an AI agent

Findings from an automated review of commit e0ed30aedbfe36e919649718b067705b52233249. Verify each one against the current code before changing anything, fix only those that still apply, and keep each fix to the lines it names.

---

F1 · Note · tests · apps/web/src/components/settings/custom-ingest-keys-section.tsx:168-174
Custom-key form rules and create→reveal flow have no test
This section adds rules the server enforces with a 400 (rate-limit bounds, reserved `org_id`/`maple_*` keys, duplicate or valueless attribute rows) and a one-time secret that is only ever returned by create and roll, and none of it is exercised by a test, while the sibling `roll-api-key-dialog.browser.test.tsx` pins exactly that secret-survival property for API keys. A regression in `formValid` or a dropped reveal would ship unnoticed.
Suggested fix: Add `custom-ingest-keys-section.browser.test.tsx` along the lines of `roll-api-key-dialog.browser.test.tsx`: mock `useAtomSet` in `@/lib/effect-atom`, then assert that an attribute row with a reserved key or a duplicate disables submit, and that a successful create renders the returned `secret` in the reveal dialog.

Production impact

Production traffic of the changed files (last 7 days)

File	Calls/day	Busiest operations
apps/web/src/components/settings/custom-ingest-keys-section.tsx	1.3M	POST /v1/traces 460k/day, 0.0% err POST /v1/traces 314k/day, 0.0% err POST /v1/metrics 188k/day, 0.0% err

What was checked

• Partial updates: the toggle sends only enabled, and OrgCustomIngestKeysService.update leaves omitted fields unchanged
• Form validation mirrors the server: reserved org_id/maple_*, duplicate keys, rate limit 1–100000, non-empty values
• expires_at is sent as toISOString(), matching the ISO pattern in packages/domain/src/http/v2/envelopes.ts:15

Observability coverage: 0 of 1 changes observable

Change	Kind	Observable	Evidence
Browser calls to /v2/ingest_keys/custom (list/create/update/roll/delete)	client call	no	apps/web fetches through MapleApiV2AtomClient; the web app has no client-side span convention (sibling sections call the same client without spans)

_{e0ed30a · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[Makisuo]

Re F1 (no test for the form rules and reveal flow): added custom-ingest-keys-section.browser.test.tsx in 6d4eff0, modelled on roll-api-key-dialog.browser.test.tsx. It checks that submit stays disabled for a valueless row, a reserved key in any case (Maple_Org_Id) and a duplicate key, that the create payload is exactly what the API expects, and that the returned secret is masked until revealed and then matches. Removing the missing-value guard from formValid makes it fail.

[maple-review-bot]

Note

⏳ Maple is reviewing this pull request at 6d4eff0. This comment updates with the review when it finishes.

[maple-review-bot]

Maple review

🟢 Confidence 9/10 · safe to merge
The head change since the last review is the browser test plus a generated file; the test exercises the form rules and the reveal it was asked to pin.
_{quality 100/100 · no findings · tests covered · risk low}

Adds the Custom keys section to Settings → Ingestion (create/edit/roll/delete, one-time secret reveal) and the browser test that was missing at e0ed30a. UI-only, safe to merge.

• CustomIngestKeysSection renders, creates, edits, rolls and deletes custom ingest keys
• customIngestKeysListAtom pages ingestKeys.listCustom into one atom
• New browser test pins form validation, the create payload and the masked reveal

Fixed since the last review

• ✅ F1 · Custom-key form rules and create→reveal flow have no test

Production impact

Production traffic of the changed files (last 7 days)

File	Calls/day	Busiest operations
apps/web/src/components/settings/custom-ingest-keys-section.tsx	1.3M	POST /v1/traces 460k/day, 0.0% err POST /v1/traces 314k/day, 0.0% err POST /v1/metrics 188k/day, 0.0% err

What was checked

• Test decodes V2CustomIngestKeyWithSecret and drives real controls, so validation and reveal assertions can fail (ingest-keys.ts:122 fields match the fixture)
• maskKey keeps a 14-char prefix and a 4-char suffix, so the masked/revealed predicates in the test are meaningful (copyable-field.tsx:10)
• Only web UI changed; the custom-key endpoints and gateway live in the feat(ingest): enforce custom ingest keys in the gateway #1519 base branch

_{b5470ab · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[maple-review-bot]

Maple review

🟢 Confidence 8/10 · likely safe to merge
Create/edit payloads were checked field by field against the v2 schemas; the browser test covers the form rules and the one-time reveal only.
_{quality 100/100 · no findings · tests partial · risk medium}

Adds a Custom keys section to Settings → Ingestion: list, create, edit, enable/disable, roll and delete custom ingest keys, with the secret shown once. Payloads match the v2 ingest-key schemas, so it is safe to merge.

• CustomIngestKeysSection lists, creates, edits, toggles, rolls and deletes custom ingest keys
• Create/roll open a masked one-time secret dialog via CopyableField
• customIngestKeysListAtom pages ingestKeys.listCustom into one list

Production impact

Production traffic of the changed files (last 7 days)

File	Calls/day	Busiest operations
apps/web/src/components/settings/custom-ingest-keys-section.tsx	1.3M	POST /v1/traces 461k/day, 0.0% err POST /v1/traces 315k/day, 0.0% err POST /v1/metrics 188k/day, 0.0% err

What was checked

• Create/edit payloads match V2CustomIngestKeyCreateParams/UpdateParams and IngestKeySignal/IngestKeyAttributeMode (packages/primitives/src/index.ts:265)
• "keep" expiry omits expires_at on update only; create always sends an explicit value (custom-ingest-keys-section.tsx:189)
• ConfirmDialog derives pending from the returned promise, so the delete/roll handlers' convention is correct (confirm-dialog.tsx:67)

_{3f696ba · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[Makisuo]

Preview test (pr-1520, deployed b5470ab)

Signed in with preview:signin, drove the UI, and sent real OTLP to ingest-pr-1520.maple.dev with a key created in the UI (traces + logs, 2 req/s, service.name=qa-svc if missing, deployment.environment=qa always).

Check	Result
Create key, one-time masked secret, list row	✅
/v1/traces, /v1/logs	200
/v1/metrics	403 "This ingest key is not allowed to send metrics"
/v1/sessionEvents (click + custom rows)	403 "…not allowed to send sessions or events"
5-request burst at 2 req/s	200, 200, 429, 429, 200 · retry-after: 1
Unknown maple_ik_ key	401
Disable toggle	200 → 401 within 40 s
Re-enable + roll	old secret 401, new secret 200
Delete	401
Stored span (sent with deployment.environment=prod, no service.name, spoofed maple_ingest_key_id)	deployment.environment=qa, service.name=qa-svc, maple_ingest_key_id=ingk_v9SD…, maple_ingest_key_type=custom

Create	List

Trace facets (env qa, service qa-svc)	Span resource attributes

Walkthrough recording: preview-walkthrough.mp4

Not covered on the preview: the sender-key-id strip from #1519 (3f696ba) was still deploying; it is pinned by default_keys_get_no_key_id_stamp_or_overrides.

[maple-review-bot]

Maple review

🟢 Confidence 8/10 · likely safe to merge
Every hunk read; the id round-trip, create/update payload names and the one-time-secret reset logic check out against the domain schemas.
_{quality 100/100 · no findings · tests partial · risk low}

Adds the custom ingest key UI: a Keys tab in Settings → Ingestion, a full-page create/configure form, a key page with usage, pause/roll/delete and a one-time secret, plus the auth docs section. Browser-only and contained; safe to merge.

• IngestionSection gains Setup/Keys/Attribute mappings tabs driven by ?view=, ?key= and ?keyView=
• IngestKeyForm creates and configures a key (signals, rate limit, expiry, attribute overrides) with a live attribute preview
• IngestKeyDetail shows activity and 24h span/log volume and pauses, resumes, rolls or deletes the key
• A rolled or created secret is held in memory and dropped when the key page is left

Production impact

Production traffic of the changed files (last 7 days)

File	Calls/day	Busiest operations
apps/web/src/components/settings/ingest-keys/shared.ts	1.2M	POST /v1/traces 467k/day, 0.0% err POST /v1/traces 255k/day, 0.0% err POST /v1/metrics 187k/day, 0.0% err

What was checked

• Raw CustomIngestKeyId is what /custom/:id endpoints decode ingk_… into, so toPublicKeyId/fromPublicKeyId usage matches packages/domain/src/http/v2/ingest-keys.ts:363
• Create/update payload field names match V2CustomIngestKeyCreateParams, and key-form.browser.test.tsx:92 pins the exact payload
• toastExit returns a success boolean (apps/web/src/lib/error-toast.ts:41), so the if (!toastExit(...)) return guards and refreshes behave

_{0a8d913 · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[maple-review-bot]

Maple review

🟢 Confidence 7/10 · likely safe to merge
The new useIngestKeyCrumbs sits after reachable early returns in a shared route component, a crash path no test covers.
_{quality 90/100 · 1 warning · tests partial · risk medium}

Rebuilds the Ingestion settings tab into Setup, Keys and Attribute-mappings views, with a custom-key table, a key page (one-time secret, volume, pause/roll/delete) and a sectioned key form. The UI work is sound, but the breadcrumb hook added to the settings route breaks the rules of hooks on the retired-tab redirect path.

• Settings → Ingestion splits into setup, keys and mappings views driven by ?view=/?key=/?keyView=
• IngestKeysTable lists default and custom keys with status, signals, limits and a filter
• Key pages show the one-time secret with env/collector/browser snippets, a 24h volume chart and pause/roll/delete actions
• Settings breadcrumbs read key names through useIngestKeyCrumbs in the settings route

Findings

🟠 Warning · F2 · useIngestKeyCrumbs runs after the legacy-tab early returns and crashes /settings?tab=developer

correctness · apps/web/src/routes/settings.tsx:75

SettingsPage returns <Navigate> for the retired tabs (settings.tsx:63-72) before this hook runs, so that render calls fewer hooks than the redirect's re-render of the same component, which now reaches useIngestKeyCrumbs (it calls useAtomValue and useNavigate). React throws "Rendered more hooks than during the previous render" and the settings page falls to the error boundary instead of redirecting. Call the hook (and the activeTab it needs) above the redirects, as resolveActiveSettingsTab is a pure function.

	const activeTab = resolveActiveSettingsTab(search.tab, visibleItems)
	const keyCrumbs = useIngestKeyCrumbs(activeTab === "ingestion" ? search.key : undefined, search.keyView)

	// Pre-hub deep links: these tabs moved to the Integrations hub.
	if (search.tab === "connectors" || search.tab === "integrations") {
		return <Navigate to="/integrations" replace />
	}
	if (search.tab === "escalations" || search.tab === "ai") {
		return <Navigate to="/settings" search={{ tab: "automation" }} replace />
	}
	// "API Reference" is now the reference block at the foot of the API Keys page.
	if (search.tab === "developer") {
		return <Navigate to="/settings" search={{ tab: "api-keys" }} replace />
	}

🤖 Prompt to fix this finding with an AI agent

Findings from an automated review of commit 6204865545ebc29deaf3ac1d200fafb3fbfe1992. Verify each one against the current code before changing anything, fix only those that still apply, and keep each fix to the lines it names.

---

F2 · Warning · correctness · apps/web/src/routes/settings.tsx:75
`useIngestKeyCrumbs` runs after the legacy-tab early returns and crashes `/settings?tab=developer`
`SettingsPage` returns `<Navigate>` for the retired tabs (`settings.tsx:63-72`) before this hook runs, so that render calls fewer hooks than the redirect's re-render of the same component, which now reaches `useIngestKeyCrumbs` (it calls `useAtomValue` and `useNavigate`). React throws "Rendered more hooks than during the previous render" and the settings page falls to the error boundary instead of redirecting. Call the hook (and the `activeTab` it needs) above the redirects, as `resolveActiveSettingsTab` is a pure function.
Replace those lines with:
	const activeTab = resolveActiveSettingsTab(search.tab, visibleItems)
	const keyCrumbs = useIngestKeyCrumbs(activeTab === "ingestion" ? search.key : undefined, search.keyView)

	// Pre-hub deep links: these tabs moved to the Integrations hub.
	if (search.tab === "connectors" || search.tab === "integrations") {
		return <Navigate to="/integrations" replace />
	}
	if (search.tab === "escalations" || search.tab === "ai") {
		return <Navigate to="/settings" search={{ tab: "automation" }} replace />
	}
	// "API Reference" is now the reference block at the foot of the API Keys page.
	if (search.tab === "developer") {
		return <Navigate to="/settings" search={{ tab: "api-keys" }} replace />
	}

Production impact

Production traffic of the changed files (last 7 days)

File	Calls/day	Busiest operations
apps/web/src/components/settings/ingest-keys/shared.ts	1.2M	POST /v1/traces 466k/day, 0.0% err POST /v1/traces 255k/day, 0.0% err POST /v1/metrics 186k/day, 0.0% err

What was checked

• The View traces link's resourceAttributeFilters shape matches the /traces search schema (apps/web/src/routes/traces/index.tsx:63)
• Key ids round-trip through CustomIngestKeyPublicId encode/decode, so row links, crumbs and mutations agree
• Search objects replace rather than merge, matching search: (prev) => ... used elsewhere in apps/web

_{6204865 · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[maple-review-bot]

1 inline note from Maple's review. The score and summary are in the review comment above.

[Makisuo]

Preview test on 6204865 (app-pr-1520). A key was created in the UI with traces and logs only, 2 req/s, service.name=qa-svc (if missing) and deployment.environment=qa (always). Requests went to ingest-pr-1520:

active:  traces 200, logs 200, metrics 403
burst x5 (2 req/s): 200, 200, 429, 429, 429
key page after 1 min: Live, last data 1m ago, 3 spans · 1 logs, bar in the current hour
pause "Until I resume", after the 60s gateway cache: traces 200, 200, 200
  (the rate limit is skipped; the drop comes first)
key page 1 min later: still 3 spans · 1 logs, last data unchanged  -> paused data not stored
resume, after the cache: traces 200 -> 4 spans, Live
roll: new secret 200; old secret after the cache 401
delete: list empty; secret after the cache 401

Live	Paused (dropped requests not stored)

The migration applied cleanly on the preview Neon branch (the deploy is green). The QA key was deleted.

[Makisuo]

Re the 7/10 review: right, useIngestKeyCrumbs ran after the retired-tab redirects. Fixed in 85461366eb: it now runs before them, keyed on search.tab, so every render calls the same hooks.

[maple-review-bot]

Maple review

🟢 Confidence 9/10 · safe to merge
The only change since the last review moves useIngestKeyCrumbs above the retired-tab redirects, where it now runs unconditionally; no test pins the ordering.
_{quality 100/100 · no findings · tests partial · risk low}

SettingsPage now reads the ingest-key crumbs before the retired-tab redirects, so /settings?tab=developer and its neighbours no longer render a different number of hooks. The hook ordering fix is the whole change since the last review; safe to merge.

• useIngestKeyCrumbs runs unconditionally at the top of SettingsPage, before the legacy-tab Navigate returns

Fixed since the last review

• ✅ F2 · useIngestKeyCrumbs runs after the legacy-tab early returns and crashes /settings?tab=developer

Production impact

Production traffic of the changed files (last 7 days)

File	Calls/day	Busiest operations
apps/web/src/components/settings/ingest-keys/shared.ts	1.2M	POST /v1/traces 467k/day, 0.0% err POST /v1/traces 255k/day, 0.0% err POST /v1/metrics 186k/day, 0.0% err

What was checked

• The redirects at settings.tsx:66-75 now all follow useIngestKeyCrumbs (settings.tsx:63), so every render calls the same hooks
• The crumb hook is fed undefined unless tab=ingestion (settings.tsx:63), so other tabs still skip the key-list fetch

_{8546136 · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[Makisuo]

Superseded by the Sources stack (#1535, #1536, #1537, #1538): custom ingest keys became push sources with the same rules, alongside integration sources and one health model.