Operations Sentry — Suggestions

Each item is a candidate for a future Linear ticket. Items already filed as tickets are listed in the completion-report under “Follow-ups”.

Platform-wide

• Adopt the arda-common 8.3.0 primitives in accounts-component — tracked separately as PDEV-533. The same Component.build() wiring plus a SentryRequestSession plugin in its Main.kt should make adoption a sub-day task. Run the dev verification recipe from the new how-to to confirm.
• Publish an internal sentry-ktor server plugin — every Ktor consumer of arda-common will need the manual SentryRequestSession plugin until Sentry publishes a server-side Ktor plugin. Worth factoring into arda-common as cards.arda.common.observability.ktor.RequestSession so the per-consumer copy-paste goes away. Low effort, high duplication-reduction.
• PiiScrubber allow-lists need governance — the allow-list is hard-coded inside common-module. Adding a new safe-to-log header today requires a common-module release. Consider externalising to a runtime configuration (env var or config file) so a new safe header can be added without a version bump, while the default allow-list stays code-owned.
• Documint outbound visibility deserves a deliberate review — the JVM OTel agent captures Documint as a generic http.client span, which is enough to know latency and HTTP status but loses semantic context (which document was rendered, was it a Card vs Label vs breadcrumb). PDEV-491’s client-side plugin would address this. Worth scoping into Q3 instead of leaving open-ended.

Operations-specific

• Standardise the fire-and-forget pattern across the codebase — CsvUploadService is now correct, but a quick grep for launch { inside routing { ... } blocks will likely surface other request-scope leaks. Worth a small audit + refactor sprint.
• Logback Sentry appender minimumEventLevel — currently at ERROR, which captures log.error(...) calls. WARN may be appropriate for a narrow set of business-impact warnings (e.g. partial Amazon import responses) but creates noise if applied wholesale. Worth a tagged-logger pattern: a dedicated logger name with WARN threshold for known-actionable warnings.
• OTEL_*_EXPORTER=none is a workaround, not a fix — the bundled agent should ideally not enable the OTLP exporter when no collector is configured. Worth raising upstream with the Sentry Java team, or pinning to a lighter agent variant if one exists.

Infrastructure-specific

• Unify the partition-secrets story — PDEV-541 covers the actual unification work. The collision discovered during this project (existing non-CDK Alpha00X-Secrets stack with 6 legacy credentials) is a clear “do this before adding the next partition secret” item.
• amm.sh is becoming a script of scripts — the per-phase invocation pattern (pre-CFN → Infrastructure CDK → EKS observability → per-partition CDK) is repeated four times across partitions and growing. Consider extracting partition iteration into a config-driven loop with one phase function each, so adding Alpha003 or a new phase is a config edit, not a script edit.
• ExternalSecret CRDs deserve a templating helper — the boilerplate around remoteRef.key/property plus the .Values.global.purpose lookup pattern is repeated for every partition secret the operations chart consumes. A small Helm template helper ({{- include "operations.partitionSecret" (dict "name" "SentryScrubSalt" "property" "salt") }}) would catch the .Release.Namespace mistake by construction.

Frontend-specific

• tracePropagationTargets regression test belongs in E2E — the unit tests in PR #845 guard the helper’s behaviour with each env name, but the actual failure mode (BFF drops propagation because env name was unmapped) is only visible end-to-end. Worth a smoke test that asserts sentry-trace and baggage headers propagate from the browser through the BFF to the BE on a representative path.
• Sentry init paths are duplicated three ways — sentry.client.config.ts, sentry.server.config.ts, sentry.edge.config.ts each carry similar option blocks. After PR #845 they all consume the same tracePropagationTargets helper; the remaining options (release, environment, tunnel, sample rates) could similarly factor into a shared sentryOptions(env) function.

Documentation-specific

• The sentry-integration.md how-to should grow a “running locally” section — current content covers dev/stage/demo/prod env provisioning but does not show how a developer runs the SDK locally against a local Sentry, or how to selectively disable Sentry during local development without breaking the boot.
• Roadmap closure tooling — the rename-and-grep dance described under “Documentation cross-link rot is the long-tail cost of moves” in learnings.md is mechanical. A scripts/promote-roadmap-project.sh that git mvs the directory and grep-replaces inbound references across all sibling repos would automate it.
• workbooks/notebooks/<project>/ lifecycle convention — the workbook stays under notebooks/operations-sentry/ indefinitely. There is no convention for archiving completed-project workbooks. Either commit a convention (move to notebooks/archive/) or document explicitly that completed workbooks stay in place — current ambiguity is paper-cut territory.