Skip to main content

The Diagnostic Cockpit

You've just changed a Cosmos patch method, or a stored procedure, or the geometry math. How do you check it against real Azure services without standing up a whole consuming app and clicking through a UI to reach that one code path? That's what Alert.CA.Infrastructure.TroubleshootAPI is for: a standalone ASP.NET Core Web API that puts a REST endpoint in front of every repository and service in the package.

The one idea to hold on to​

It's a thin cockpit over the package — one controller per subsystem, each just injecting the same interfaces your apps do and calling them. There's a CamerasController over the Cosmos camera repositories, a LocationsController over the SQL geometry stack, a BlobController, an ImageMetadataController, a CommunicationController, and so on across every backend. The controllers hold no business logic of their own; they exist so you can invoke the real thing directly and see what comes back — against real dev-environment Azure, not mocks.

Because it resolves the same interfaces through the same Add… extension methods, it's also the fastest way to confirm your registration is correct: if a repository isn't wired up, the controller that needs it fails to resolve on the first call.

Gotcha: this talks to real Azure, and it's not for end users

The Troubleshoot API connects to the same Azure services as production apps, through Azure App Configuration. A write endpoint writes real data in whatever environment your AppConfig endpoint points at — point it at dev, not prod, unless you mean it. It is a development and operations tool, deliberately not exposed to end users.

Running it​

Set the App Configuration endpoint in appsettings.Development.json and launch the Alert.CA.Infrastructure.TroubleshootAPI profile:

{
  "Endpoints": {
    "AppConfig": "https://appcs-wfca-ca-config-alertca-dev-001.azconfig.io"
  }
}

Swagger UI at /swagger lists every controller and lets you call endpoints interactively — the practical front door for "does my change do what I think against real data?"

Wrapping up​

The Troubleshoot API is a controller-per-subsystem cockpit over the whole package: it injects the same interfaces your apps do, so it both exercises real behavior against real dev Azure and doubles as a registration smoke test. Mind that its writes are real, keep it pointed at a non-production environment, and reach for /swagger when you need to poke a single code path.

That's the full spine — registration, five storage backends, the service layer, and the tool that drives them all. Back to where it started: The Shared Spine.