Application Insights bugs tend to fall into one of two categories. Either the SDK sends something and you never see it in the portal - wrong connection string, wrong environment variable, telemetry initializer stripping the data - or it sends something you did not intend, and you only find out a week later when billing shows an unexpected spike. Both categories share one root cause: there is no fast, local feedback loop.

The standard debugging advice is to enable DiagnosticsTelemetryModule, or to tail the Fiddler capture, or to deploy to a dev environment and wait for the portal to ingest the data. All of those paths are slow. Some require a cloud subscription you might not have access to from the machine you are debugging on.

Topaz emulates the Application Insights ingestion API (/v2/track) and the query API (/v1/apps/{ikey}/query) locally. The SDK points at localhost, sends telemetry as it normally would, and you can query the ingested data immediately - from code, from the Topaz Portal, or from a KQL query in your terminal.

This week in Topaz: Azure App Configuration launches as a new first-class service with store and replica lifecycle management, soft-delete, and purge support. Azure Application Insights joins as a new service with CRUD component management, telemetry ingestion, and log query endpoints. Private Endpoint management arrives for virtual networking. Blob and Queue Storage gain Hierarchical Namespace (HNS/ADLS Gen2) and hardened geo-replication secondary-endpoint rejection. App Service grows with publishing credentials and Kudu authentication. Service Bus improves session dead-lettering and dead-letter property propagation. Background service health reporting is enriched with execution timestamps.

This week in Topaz: Azure Log Analytics launches as a new first-class service with workspace management, data ingestion, and soft-delete support. Cosmos DB gains Entra ID data-plane authorization with resource-scoped RBAC, GROUP BY/ORDER BY query support, and an expired document purge scheduler. Blob Storage adds geo-replication sync simulation. ARM expands with management group child retrieval, tenant-level resource provider listing, and tenant function support in deployment parameters. Service Bus gains a message expiry scheduler and dead-letter forwarding. The VS Code extension is now documented.

When I started working on Topaz 15 months ago (I pushed the first commit in the middle of April 2025), I had no idea how the landscape of software engineering would change by the time I wrote this. I wanted to summarize the whole journey and describe how AI changed the way I design, develop and test Topaz — a local Azure emulator I've been building in the open.

This week in Topaz: Azure App Configuration is fully implemented with data plane key-value management, access key operations, and Azure CLI support. Service Bus gains session-based messaging with session lock management, wildcard session attachment, and dead-letter queue semantics. Blob Storage now enforces authentication for private containers. ARM deployment operations are now tracked across all four scopes. Container Registry receives async Docker build execution. The Topaz CLI gains defaults and health management commands.

There is a certain category of test that feels good to write but does not actually test what you think it does. Retry logic sits squarely in that category.

The usual pattern is this: inject a fake HttpMessageHandler, make it return a 429 or 503 on the first N calls, assert that the code retried and eventually succeeded. The test passes. You ship with confidence. Then, in production, a real throttling event triggers a path through the Azure SDK that your mock never covered, and the retry policy does not behave the way the test implied.

The issue is not that the mock is wrong. It is that the mock bypasses the entire SDK transport layer. When you return a 429 from a fake handler, you are testing whether your own retry wrapper handles it correctly. You are not testing whether Azure.Core's built-in retry pipeline fires, whether the Retry-After header is respected, or whether the SDK's own exception hierarchy propagates through your application code the way you assumed. That is a different bar entirely.

For a while, local Azure development in my projects looked like this: Azurite for Blob and Queue Storage, the Microsoft Service Bus Emulator for messaging, the Cosmos DB Emulator for document storage, and nothing at all for Key Vault, Container Registry, or Entra. The last three were either skipped in local runs, mocked, or simply hit against a real Azure subscription when I needed them.

That worked, to a point. But the setup cost was real. Each emulator has its own Docker image, its own port range, its own quirks, and its own certificate story. Compose files grew. CI pipelines grew to match. And the services that had no emulator at all stayed untested locally, which is exactly the category where surprises tend to show up in production.

I wanted to see whether a single tool could cover the whole stack without making too many compromises.

This week in Topaz: Azure Cosmos DB gains full SQL query execution with schema-aware document CRUD, partition range planning, and QueryEngine refactoring. Entra ID adds device code authentication with an interactive HTML authorization flow for headless and CLI scenarios. Service Bus introduces authorization rules for namespace and entity-level access control. Documentation and onboarding receive major updates, including architecture guides, installation improvements, and wildcard DNS support for certificate generation.

Every team that tests against real Azure services in CI eventually hits the same four problems. You need credentials for the pipeline. Those credentials need to be stored somewhere, rotated, and audited, and if they leak they affect a real environment. The tests themselves become flaky because Azure provisioning has variable latency and your Service Bus namespace occasionally takes three minutes to appear. And if you run on private agents, you need to add networking complexity on top of all of that.

These are not Azure-specific problems. They show up in any pipeline that depends on external cloud services. But the fix for them often is Azure-specific, and the usual answers (use a dedicated test subscription, use Managed Identity, sanitize your test fixtures) treat the symptoms without changing the fundamental structure of the problem.

I wanted to see whether running tests against a local Azure emulator in CI could close those gaps cleanly. The short version is: it can, and the job runs in 38 seconds.

One of the fundamental rules of Topaz is that it must not require sudo or admin rights. There is nothing more frustrating than having to request elevated permissions on your machine just to run a dev tool.

For most Azure CLI operations this is not a problem. You point the CLI at https://topaz.local.dev:8899, it talks to port 8899, done. ROPC login is the exception - az login --username --password triggers a user-realm discovery pre-flight inside MSAL that always targets port 443, regardless of what port you configured in the authority URL. On a non-Docker Topaz install, nothing is listening on port 443, because binding that port requires root. The result is a connection timeout that surfaces as an opaque account-not-found error with no indication that port 443 is involved at all.

This post explains the MSAL assumption behind that behavior, why the straightforward fixes do not work without elevated permissions, and how a built-in HTTP CONNECT proxy on port 44380 closes the gap cleanly.