Frequently asked questions about Kronikol.

Do I need to change production code?

No — most extensions use DI decoration (DecorateAll<T>), DelegatingHandlers, or DiagnosticSource listeners. Tracking is added entirely in your test project's ConfigureTestServices. A few extensions offer optional one-token changes (e.g. .BuildTracked() for Kafka) but these are no-ops outside test context.

Why is my dependency showing as "Unknown"?

Test identity isn't propagating to the thread running the dependency call. This is common with background threads, change feed processors, and hosted services. See Background Thread Correlation for the resolution chain (HTTP headers → delegate → TestIdentityScope.Current → GlobalFallback) and how to wire each level.

What's the difference between MessageTracker and TestTrackingMessageHandler?

TestTrackingMessageHandler is a DelegatingHandler for HTTP pipelines — it intercepts HttpClient calls. MessageTracker is for non-HTTP messaging (Service Bus, Kafka, EventHubs, etc.) and provides TrackSendEvent() / TrackConsumeEvent() / TrackSendMessage() methods. See Event & Message Tracking for a detailed comparison.

Why is my diagram empty?

The most common cause is forgetting to enqueue the test context. In your fixture's DisposeAsync():

DiagrammedTestRun.TestContexts.Enqueue(TestContext.Current);

Run with DiagnosticMode = true for a detailed breakdown. See Diagnostics and Debugging.

My diagrams are too wide / have massive token strings

See Filtering and Redacting Diagram Content — My Diagrams Are Too Wide. The quickest fix is RequestResponseLogger.MaxContentLength = 2000; in test setup.

Why does a diagram say "Syntax Error", or a whole scenario have no diagrams at all?

A single statement longer than the engine can parse makes it abandon that fragment. Since 3.0.48 labels are capped at generation time and the failure block names the offending line; before that, very long coloured note bars could crash the engine outright. See Large Response and Diagram Handling › Statement-Length Limits (3.0.48+).

Can I use this without a PlantUML server?

Yes — two options:

1. Browser-side rendering (default): A TeaVM-compiled PlantUML engine is fetched from the jsDelivr CDN on first page load (then cached) and runs entirely in the browser. No server needed. See PlantUML Browser Rendering.
2. IKVM local rendering: Runs PlantUML in-process via IKVM (Java-to-.NET bridge). No network calls. See Integration PlantUML IKVM.

How do I track Change Feed processing in parallel tests?

Use the TestCorrelationStore system (v2.36.0+). The CosmosDB tracking extension auto-populates correlations on write, and ChangeFeedCorrelation.Wrap<T>() resolves them at processing time. No production code changes needed. See Parallel-Safe Background Correlation.

My consumer is tracked but downstream HTTP calls show as "Unknown"

This usually means a decoupled processing pattern — the consumer thread has AsyncLocal set but passes work through a Channel<T> or queue to a processing thread that doesn't. Wrap the processing side with ProcessingCorrelation.Wrap<T>(). See Parallel-Safe Background Correlation › Setup Guide: Decoupled Kafka/ServiceBus Consumer.

What's the difference between GlobalFallback and TestCorrelationStore?

GlobalFallback is a single process-wide static — only safe for serial execution. TestCorrelationStore is a concurrent dictionary keyed by work-item, so each test's operations are attributed correctly even under parallel execution. Use TestCorrelationStore for new code; GlobalFallback for legacy serial-only fixtures. See Parallel-Safe Background Correlation › Comparison Table.

How does test identity propagation work?

Four-level resolution chain, checked in order:

1. HTTP request headers (test-tracking-current-test-name / test-tracking-current-test-id) — propagated by TestTrackingMessageHandler, and (4.13.0+) by GrpcTrackingInterceptor in a gRPC call's metadata
2. CurrentTestInfoFetcher delegate — set on options, framework-specific
3. TestIdentityScope.Current — AsyncLocal ambient scope (for background threads)
4. TestIdentityScope.GlobalFallback — static fallback (for pre-existing threads)

See Background Thread Correlation for setup examples.

How do I see what's being tracked at runtime?

Enable diagnostic mode:

new ReportConfigurationOptions { DiagnosticMode = true }

This generates a DiagnosticReport.html alongside your test report showing all registered tracking components, unmatched client names, unknown entries, and HttpContextAccessor status. See Diagnostics and Debugging.

After the run, kronikol query services lists every service and dependency the report actually saw (a service missing from the table was never called), without opening the report file. See Querying Reports.

Does Kronikol detect flaky tests?

Yes, from 3.9.0, and without a server: every run reads an append-only ledger committed in your repository (Cross-Run History) and says, per scenario, whether a failure is a regression (broke), has been failing since a particular run, or flips (flaky — measured as a flip rate across runs, so a suite that never retries still gets a verdict). It shows in Failures.md, the CTRF document, the run-end pointer, kronikol query history, and on the labs page beside the report (TestRunReport.labs.html, since 4.6.0) as a sparkline and verdict for each scenario; ShowScenarioHistory puts them in the report itself, with $flaky in the search. kronikol history gate fails a build on what is new while tolerating what is known to flip, and kronikol history quarantine parks a scenario with a reason on file. What it does not do: re-run tests to see whether they flip (that is your runner's retry, which Kronikol records as attempts), or host a dashboard.

Why is my first scenario slow?

Often because it went first and paid the app's one-time warm-up (the JIT, a schema build, a first connection). From 4.8.0 Kronikol marks those calls, leaves them out of kronikol query summary's Slowest and says where the time went: Why is my first scenario slow?.

• How-To Guides — Step-by-step task guides
• Quick Start (xUnit) — Get started in 5 minutes
• Diagnostics and Debugging — Troubleshooting empty reports and missing entries
• Querying Reports — Answer questions about a run from the command line, without opening the report