webapi-exceptions
Central exception-logging Web API (.NET 8) that estate services report errors to via the TC.Exceptions.WebApiClient packages, storing them in the shared EventLog database, with a Blazor reader UI for browsing them.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | ASP.NET Core 8, Blazor, Dapper |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2026-05-08 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 3 release pipeline(s): \finance\webapi-exceptions; \tools\Web Exceptions Reader; webapi-exceptions Stealth |
| Integration | rest, sqlserver |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loosely attached Bound into the core by 1 mechanism(s).
- Shares core database sqlserver:EventLog
Detaches when the shared database group it belongs to gains an owned API or completes schema separation (sqlserver:EventLog).
Capability duplication
Part of the Exceptions packaging family (consolidate): Publishes overlapping TC.Exceptions.* packages
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
Not applicableNot a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Retirement or consolidation candidate; do not invest in ZDD adoption.
SQL Server exit
Retire insteadThis repo is a retirement or consolidation candidate. Do not invest in a database migration; execute the retirement and the SQL Server dependency disappears with it.
Containerisation
Retire insteadThis repo is a retirement or consolidation candidate; containerising it would be investment in something we intend to switch off.
Recommended actions
Consolidate webapi-exceptions into the surviving exceptions packaging path
Publishes overlapping TC.Exceptions.* packages. Consolidate publishing into tc-exceptions, and put real tests around it before further change: it is a stage 2 chokepoint with 71 dependents and one placeholder test.
Impact: Removes a duplicated capability
proposedAssessment notes
webapi-exceptions
Purpose
The estate's central exception sink: services call the versioned Exceptions Web API (via the TC.Exceptions.WebApiClient / .AspNetCore NuGet packages published from this repo, alongside TC.Exceptions.Contract) to record unhandled and logged exceptions, which are written to the shared EventLog SQL Server database. TC.Exceptions.Reader is a Blazor web app (the \tools\Web Exceptions Reader deployment) for browsing and triaging logged exceptions.
Tech stack
Modern SDK-style solution (.slnx, central package management via Directory.Packages.props, StyleCop + Sonar/SecurityCodeScan analysers, Nerdbank.GitVersioning). API is ASP.NET Core on .NET 8 with Asp.Versioning (V2/V3 endpoints), FluentValidation, Swashbuckle/NSwag, PhenixAuth and Correlate; data access is Dapper over TC.Data.EventLog unit-of-work; Fastenshtein is used for fuzzy matching. Client packages multi-target net462/net472/netstandard2.0/net8.0 (contract also net10.0) so full-framework consumers can still report exceptions.
Deployment
prod_application with 3 releases from build pipeline webapi-exceptions (YAML build2.yml using shared azure-pipelines-templates): release pipelines \finance\webapi-exceptions, webapi-exceptions Stealth, and \tools\Web Exceptions Reader for the Blazor UI. Also publishes the three client NuGet packages to the internal Production feed.
Dependencies
Internal: TC.ConnectionBroker (Api/Sql - since v10 the client resolves the API base URL through the API connection broker) and TC.Diagnostics.HealthChecks. No external services.
Data stores
The shared EventLog SQL Server database (DbUnitOfWork.DatabaseTarget = "EventLog"), which several other estate services also read/write.
Integration points
Inbound REST from effectively every estate service via the WebApiClient packages; direct SQL to EventLog.
Code health
Good: nine test projects (~168 test files) spanning unit, per-API-version, integration and end-to-end suites; well-maintained README with a versioned breaking-change history (v8-v10). Analyser suite enforced build-wide. Last commit 2026-05-08.
Modernisation risks
Low priority - already .NET 8 with strong tests and CI. Main risks are structural: extremely high fan-in (a client-package breaking change ripples across the estate, as the v8-v10 history shows) and coupling through the shared EventLog database. Note the package-family split with the tc-exceptions repo: TC.Exceptions/TC.Exceptions.Logging come from tc-exceptions while TC.Exceptions.Contract/WebApiClient* are built here, so dependency edges attributed to tc-exceptions may actually belong to this repo.