[myieye]

PR CI never ran Lexbox's production exception handler. The CI cluster (deployment/gha) builds on local-dev, so Lexbox runs as Development, and Program.cs only adds UseExceptionHandler outside Development. Every PR's integration tests therefore saw the developer exception page. The production path (the StatusCodeSelector status mapping and CustomizeProblemDetails) was only exercised at release, when the integration suite runs against staging.

• ErrorHandling:UseProductionExceptionHandler now decides whether UseExceptionHandler is added. It defaults to !IsDevelopment(), so local dev, develop (Staging), staging and production behave exactly as before. In Development WebApplication still adds the developer exception page, but as the outermost middleware, so an explicitly added exception handler catches exceptions first.
• The gha cluster turns the flag on (deployment/gha/lexbox.patch.yaml), so PR integration tests see production-shaped errors.
• Analytics are explicitly off in the gha cluster. Local-dev turns them on, and if the cluster ever stopped running as Development, Lexbox would use the production Mixpanel token.
• Removed deployment/gha/app-config.yaml. It only repeated base's environment-name: "Development"; local-dev's app-config patch doesn't change that key.

Why not run CI as Staging? Without Development the throwaway cluster has no JWT secret (it comes from appsettings.Development.json), no OAuth signing keys (local-dev deletes the cert-manager resources) and no plain-http OAuth. Those should stay tied to Development. Test-user seeding works in Staging too, and the testing endpoints depend on #if DEBUG, not the environment.

#2884 (FwHeadless status mapping) is the first change whose production error path this covers.

Test plan

• GHA integration tests (dotnet and playwright) pass with the production handler on
• The ProjectBlockingTests 404/423 assertions still hold under the production handler once Report FwHeadless failures with one exception and one status mapping #2884 is in

---

Generated by Claude Code

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: d113ba79-1f45-44a7-afc7-a7c6a60e6ffc

Commits

Reviewing files that changed from the base of the PR and between 2459e09 and 3ff167c.

Files selected for processing: 4

• backend/LexBoxApi/Program.cs
• deployment/gha/app-config.yaml
• deployment/gha/kustomization.yaml
• deployment/gha/lexbox.patch.yaml

Files with no reviewable changes: 2

• deployment/gha/kustomization.yaml
• deployment/gha/app-config.yaml

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Walkthrough

The application now reads ErrorHandling:UseProductionExceptionHandler to control production exception-handler registration. The setting defaults to enabled outside Development and disabled in Development. The GHA deployment sets the setting to true, disables analytics, and removes the app-config ConfigMap and its Kustomization entry.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: Minimal · up to 3ff16

No actionable merge-blocking risk is established; the GHA deployment enables the intended production-shaped exception handling while retaining its Development environment.

Pre-merge checks: 5

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: enabling Lexbox's production exception handler in the CI cluster.
Description check		The description directly explains the production exception handler change, the GHA configuration updates, and the removal of the redundant app configuration.
Docstring Coverage		No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 1 files. (1 skipped: 1 unsupported.)

• 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

_{I’m a rabbit, thumping beside the config key.
The handler can wake in Development now.
A true setting hops into the deployment.
Analytics rests with its switch turned off.
The old ConfigMap is gone from the patch.
I nibble the diff, then bound away.}