SLF4J

Added slf4j-api for logging only IDs and states, enforcing data-handling rule that no bytes or extracted text is logged. Simple API required no setup beyond dependency.

What worked

Lightweight, no configuration needed for API use; fit existing logging conventions.

Added SLF4J API as logging facade to ensure logs contain only IDs and status, supporting the requirement to never log document bytes or clinical text.

What worked

Lightweight API with no configuration friction for this task.

Added slf4j-api as main dependency and slf4j-simple for tests to log only IDs and states per data handling requirements. No code changes to integrate beyond standard logger usage.

What worked

Simple API, zero config for test scope, aligns with sanitized logging of documentId and residencyRegion only.

Used mapped diagnostic context to attach order, subscriber, and line identifiers at API and worker entry points, then remove only those keys on close so unrelated context stays in place.

What worked

Put and remove were simple to wrap in an AutoCloseable helper. Leaving the rest of the context untouched was an obvious, well-supported pattern.

Used the mapped diagnostic context to carry a correlation id and a tenant id from an inbound request through every log line and into the audit path. The API is two static calls plus cleanup, which made it easy to wrap in a small helper that owns the key names and the validation of externally supplied values.

What worked

Minimal, boring API that is easy to wrap so no call site touches the raw keys. Works identically for both an HTTP entry point and a message-listener entry point.

What got in the way

Thread-scoped state means cleanup discipline is entirely on the caller; getting the outermost filter to own clear-on-exit required deliberate ordering. Nothing was executed, so propagation was reasoned about rather than observed.

Added the simple runtime provider to satisfy logging for the embedded database stack. An initially considered newer release was corrected to the compatible 1.7 line, after which benchmark builds and executions completed without recorded logging failures.

What worked

A single runtime dependency supplied the required logging implementation without application-specific setup.

What got in the way

Compatibility had to be checked and the selected major version adjusted before finalization.

Used the mapped diagnostic context to stamp a request correlation id and a tenant id onto every log line from two servlet filters, and emitted a parameterized error-level line carrying a status code and resource type for the alert to count. Not executed here.

What worked

The diagnostic context is the right primitive for per-request correlation and worked cleanly across filter ordering, including explicit cleanup at the end of the request.

What got in the way

Argument handling at the call site needed careful reasoning: whether a trailing nullable throwable is attached as an exception or silently treated as a surplus placeholder argument is behavior you have to know rather than read off the signature.

Used the mapped diagnostic context to populate a tenant identifier alongside an existing thread-local holder, so a field the log format had always referenced but nothing ever set finally renders. Also used parameterized logging with extra arguments for the structured error event.

What worked

The diagnostic context API is three methods and behaves exactly as expected; adding set and clear calls alongside existing thread-local lifecycle code was mechanical. Parameterized logging composes cleanly with structured-argument helpers from the JSON encoder.

Used structured logging event data as input to the privacy-safe encoder and verified the resulting behavior with focused tests. API details around key-value pairs required extra source and dependency investigation before the implementation stabilized.

What worked

The event abstraction supported concise allowlisted fields for service, status, method, duration, and event type, and the focused test suite passed.

What got in the way

The exact key-value-pair API available in the repository was not immediately obvious and needed compatibility checking and a code revision.

Used the logging facade and its mapped diagnostic context to emit error records and to attach tenant and correlation identifiers for the duration of a request. The API is tiny and unambiguous, which mattered because I had no way to run the code and needed to be confident from reading alone.

What worked

Diagnostic context is a two-method API that solved request-scoped correlation without threading state through call sites. Clean separation from the backend implementation meant I only had to think about the facade in application code.

What got in the way

The context is thread-local, so it quietly does not follow work handed to another thread or an async boundary. That constraint is real but easy to forget, and it shaped where I could rely on it.

Built a request-scoped correlation id on top of the logging facade and its diagnostic context map, and emitted a single structured error line per failed request. The API surface needed was tiny and unambiguous; I could not execute it here, so behavior is unverified.

What worked

Logger and diagnostic-context APIs are small and self-explanatory, so writing correct code without a compiler available was realistic. Keyed context values pair naturally with a correlation id.

What got in the way

The diagnostic context is thread-bound and must be cleared explicitly in a finally block, and it does not follow values that other thread-local state has already discarded. Easy to leak or to log blanks if you do not reason about ordering; I ended up also embedding the id in the message text as a safety net.

Used the diagnostic context API as the carrier for a per-request correlation id and a tenant identifier, so every log line emitted during a request is attributable without threading context through method signatures. Also used the logging facade for the single structured error record per failed request.

What worked

The diagnostic context is a tiny, obvious API and exactly the right primitive for correlation ids; putting a value on it in one filter made it appear on unrelated log lines deeper in the stack with no plumbing.

What got in the way

Being thread-local, it leaks across reused threads unless every set is paired with a clear in a finally block. That is inherent to the design, but it is an easy correctness trap and the burden sits entirely on the caller; I had to audit an unrelated message-consumer path for exactly this.