- log kehilangan correlation ID
- trace terputus di tengah request
- user identity hilang di async task
- tenant ID salah atau null
- audit event tidak bisa dikaitkan dengan command asal
- security check berjalan tanpa principal yang benar
- transaction/request-scoped object dipakai di thread yang salah

HTTP request -> container thread -> JAX-RS resource -> service layer
             -> database/client/cache/event publisher
             -> executor/Kafka callback/async worker

- JAX-RS @Context
- SecurityContext
- HttpServletRequest, jika running on Servlet container
- MDC/logging context
- ThreadLocal yang dibuat framework atau aplikasi
- OpenTelemetry current Context
- transaction context, tergantung framework

Context is not business data, but it controls whether business data can be trusted, traced, secured, and audited.

"Service ini butuh tenant ID, tapi tenant ID diambil dari ThreadLocal tersembunyi."

- tenant ID eksplisit di command/application context
- logging/tracing context tetap bisa ada di MDC/OTel context
- security context tidak disalin sembarangan ke background job

@Path("/quotes")
public class QuoteResource {

    @Context
    private UriInfo uriInfo;

    @Context
    private HttpHeaders headers;

    @Context
    private SecurityContext securityContext;

    @GET
    @Path("/{id}")
    public Response getQuote(@PathParam("id") String id) {
        String path = uriInfo.getPath();
        String user = securityContext.getUserPrincipal().getName();
        return Response.ok().build();
    }
}

@Context gives access to request/runtime metadata.
It is not a replacement for explicit application command data.

public record RequestContext(
    String correlationId,
    String causationId,
    String tenantId,
    String actorId,
    String sourceSystem
) {}

@POST
public Response submitQuote(SubmitQuoteRequest request) {
    RequestContext ctx = contextFactory.fromCurrentRequest();
    QuoteResult result = quoteApplicationService.submit(ctx, request.toCommand());
    return Response.accepted(result).build();
}

JAX-RS context should be consumed at the edge and translated into explicit application context.

private static final ThreadLocal<String> TENANT = new ThreadLocal<>();

- logging MDC
- current user
- current tenant
- current transaction
- OpenTelemetry current span/context
- framework request scope internals

Every ThreadLocal set must have a guaranteed clear in finally block.

public void filter(ContainerRequestContext requestContext) {
    try {
        TenantContext.set(resolveTenant(requestContext));
        // continue chain depending on filter model
    } finally {
        TenantContext.clear();
    }
}

- Use ThreadLocal for cross-cutting context only when framework-compatible.
- Never rely on ThreadLocal as the only source of business-critical data.
- Clear aggressively.
- Wrap executor tasks if context must cross threads.

correlation_id
causation_id
trace_id
span_id
tenant_id
actor_id
request_path
http_method
source_system

@Provider
@Priority(Priorities.AUTHENTICATION)
public class CorrelationFilter implements ContainerRequestFilter, ContainerResponseFilter {

    @Override
    public void filter(ContainerRequestContext request) {
        String correlationId = getOrCreateCorrelationId(request);
        MDC.put("correlation_id", correlationId);
    }

    @Override
    public void filter(ContainerRequestContext request, ContainerResponseContext response) {
        try {
            response.getHeaders().putSingle("X-Correlation-ID", MDC.get("correlation_id"));
        } finally {
            MDC.clear();
        }
    }
}

MDC is usually ThreadLocal-backed.
If execution moves to another thread, MDC may not follow.
If MDC is not cleared, next request may inherit stale values.

executor.submit(() -> {
    log.info("publishing quote event"); // correlation_id may be missing
});

Map<String, String> captured = MDC.getCopyOfContextMap();

executor.submit(() -> {
    Map<String, String> previous = MDC.getCopyOfContextMap();
    try {
        if (captured != null) {
            MDC.setContextMap(captured);
        }
        log.info("publishing quote event");
    } finally {
        MDC.clear();
        if (previous != null) {
            MDC.setContextMap(previous);
        }
    }
});

@Context
SecurityContext securityContext;

- Who is the caller?
- Is the request secure?
- Does caller have role X?
- Is caller a user, service, or internal platform component?

- request token may expire
- user may no longer be authorized later
- background work may need service identity, not user identity
- replayed job should be auditable as system action caused by user command

actor_id       -> who initiated
subject_type   -> user/service/system
causation_id   -> command/event that caused the work
service_identity -> identity used for outbound service call

- routing
- authorization
- data access
- product catalog
- pricing rules
- feature flags
- logging
- audit
- metrics segmentation

String tenantId = TenantThreadLocal.get();
quoteRepository.findById(quoteId); // repository implicitly filters by ThreadLocal tenant

quoteRepository.findByTenantAndId(ctx.tenantId(), quoteId);

- explicit tenant in application/domain data access path
- MDC/telemetry tenant field for debugging
- validation guard that rejects missing tenant at boundary

No tenant-sensitive operation should succeed without a known tenant boundary.

[ ] Where is tenant resolved?
[ ] Is tenant trusted from header, token claim, path, gateway, or config?
[ ] Is tenant validated against actor permission?
[ ] Does repository query enforce tenant boundary?
[ ] Does async/event processing preserve tenant context?
[ ] Are logs tenant-aware without leaking PII?

CompletableFuture.supplyAsync(() -> service.loadSomething());

- Which executor is used?
- Does it propagate MDC?
- Does it propagate OpenTelemetry context?
- Does it have timeout/cancellation?
- Does it respect tenant/security context?
- Does it have bounded queue?

Never introduce async execution without defining context, timeout, cancellation, queue, error, and observability behavior.

- MDC capture/restore/clear
- OpenTelemetry context capture/restore
- correlation ID preservation
- tenant/audit context preservation, if allowed
- exception logging
- task duration metrics
- queue metrics
- rejection handling

public final class ContextAwareExecutor {
    private final ExecutorService delegate;

    public void submit(Runnable task) {
        Map<String, String> mdc = MDC.getCopyOfContextMap();
        RequestContext requestContext = RequestContextHolder.currentOrNull();

        delegate.submit(() -> {
            try {
                if (mdc != null) MDC.setContextMap(mdc);
                RequestContextHolder.set(requestContext);
                task.run();
            } finally {
                RequestContextHolder.clear();
                MDC.clear();
            }
        });
    }
}

- previous context on worker thread
- rejected execution
- cancellation
- nested async tasks
- OTel Context
- task naming
- metrics
- security restrictions

traceparent
tracestate
X-Correlation-ID
X-Causation-ID
X-Request-ID
X-Tenant-ID, if allowed by platform standard
Authorization, if doing token forwarding or token exchange

[ ] Which headers are official?
[ ] Which headers are gateway-owned?
[ ] Which headers are internal-only?
[ ] Which headers are user-controllable and must not be trusted?
[ ] Which headers must be stripped at boundary?
[ ] Which headers are propagated to external vendors?

public class OutboundContextFilter implements ClientRequestFilter {
    @Override
    public void filter(ClientRequestContext requestContext) {
        requestContext.getHeaders().putSingle("X-Correlation-ID", Current.correlationId());
        requestContext.getHeaders().putSingle("X-Causation-ID", Current.causationId());
    }
}

Never trust inbound tenant/user headers unless they are asserted by a trusted gateway or validated against a token claim.

correlation_id
causation_id
traceparent
tenant_id
event_id
producer_service
schema_version
command_id

ProducerRecord<String, QuoteSubmittedEvent> record =
    new ProducerRecord<>("quote.submitted.v1", key, event);

record.headers().add("correlation_id", bytes(ctx.correlationId()));
record.headers().add("causation_id", bytes(ctx.causationId()));
record.headers().add("tenant_id", bytes(ctx.tenantId()));

HTTP request context and Kafka processing context are related, not identical.

HTTP command correlation_id = C1
HTTP command causation_id   = request-id-123
published event_id          = E1
consumer causation_id       = E1
consumer correlation_id     = C1

- Which request caused this event?
- Which event caused this downstream mutation?
- Which tenant was affected?
- Which service produced the event?

current span/context is associated with current execution thread

Context captured = Context.current();

executor.submit(() -> {
    try (Scope scope = captured.makeCurrent()) {
        doWork();
    }
});

[ ] Does HTTP server instrumentation exist?
[ ] Does Jersey/JAX-RS instrumentation exist?
[ ] Does HTTP client instrumentation exist?
[ ] Does Kafka producer/consumer instrumentation exist?
[ ] Does executor instrumentation exist?
[ ] Does custom thread pool preserve context?

public class QuoteService {
    @Inject
    private SomeRequestScopedContext context;

    public void startAsyncWork() {
        executor.submit(() -> {
            context.getTenantId(); // may fail or use invalid context
        });
    }
}

- request scope may be destroyed before async task runs
- proxy may throw context-not-active exception
- stale context may be used incorrectly

String tenantId = context.getTenantId();
String actorId = context.getActorId();
String correlationId = context.getCorrelationId();

executor.submit(() -> asyncProcessor.process(new AsyncContext(
    tenantId,
    actorId,
    correlationId
)));

- resource method throws exception
- client disconnects
- timeout fires
- thread is interrupted
- downstream dependency fails
- async task is rejected

try {
    setContext();
    return proceed();
} catch (Exception e) {
    recordFailure(e);
    throw e;
} finally {
    clearContext();
}

try {
    restoreContext();
    task.run();
} finally {
    clearContext();
}

1. Identify the missing/wrong context field.
2. Find where it should be created.
3. Find where it should be attached to current execution.
4. Find every boundary where execution changes thread/protocol.
5. Verify capture/restore/clear behavior.
6. Check logs before and after each boundary.
7. Check tests for context leak across test cases.

- thread name
- request ID
- correlation ID
- trace ID
- tenant ID
- actor ID
- operation name
- async task name

[ ] inbound request without correlation ID generates one
[ ] inbound request with valid correlation ID preserves it
[ ] response includes correlation ID
[ ] error response includes correlation ID
[ ] outbound HTTP call propagates approved headers
[ ] async task preserves MDC/trace if required
[ ] ThreadLocal/MDC cleared after request
[ ] two sequential requests on same thread do not leak context
[ ] Kafka event includes required context headers
[ ] Kafka consumer creates correct processing context

@Test
void clearsContextAfterFailure() {
    assertThrows(RuntimeException.class, () -> invokeFailingRequest());
    assertNull(MDC.get("correlation_id"));
}

Send request A with correlation_id=A.
Send request B with correlation_id=B.
Assert logs/outbound calls/events for B never contain A.

[ ] Does this code introduce a new async boundary?
[ ] Is the executor explicit and bounded?
[ ] Does context propagation happen deliberately?
[ ] Are MDC and ThreadLocal cleared in finally block?
[ ] Is tenant context explicit for business-critical operations?
[ ] Is SecurityContext used only within valid request lifecycle?
[ ] Are user/service identities modeled correctly?
[ ] Are correlation/causation IDs preserved across outbound calls?
[ ] Are Kafka headers populated/consumed consistently?
[ ] Are context propagation tests included?
[ ] Does code avoid passing JAX-RS framework context into domain logic?
[ ] Does logging include enough context without leaking PII?

Runtime and framework
[ ] Is the service running on Jersey, another JAX-RS implementation, Servlet container, or embedded server?
[ ] Which request filters create correlation/request/tenant context?
[ ] Which response filters clear context?
[ ] Are filters ordered explicitly?

Logging
[ ] Which logging framework is used?
[ ] Is MDC used?
[ ] Which MDC keys are standard?
[ ] Is MDC cleared on success and error paths?
[ ] Are logs structured JSON or plain text?

Tracing
[ ] Is OpenTelemetry Java agent used?
[ ] Is manual instrumentation used?
[ ] Are executor/Kafka/HTTP client instrumentations enabled?
[ ] How are trace ID and correlation ID related?

Security and tenancy
[ ] Where is tenant resolved?
[ ] Is tenant taken from token claim, header, path, config, or gateway?
[ ] Is tenant validated against identity/permission?
[ ] Is tenant passed explicitly to repository queries?
[ ] Are audit events tenant-aware?

Async and executors
[ ] Which executors exist?
[ ] Are they bounded?
[ ] Are they context-aware?
[ ] Do they propagate MDC/OTel/security/tenant context?
[ ] Do they clear context after task completion?

Kafka/events
[ ] Which context headers are required on events?
[ ] Are correlation and causation IDs populated?
[ ] Is tenant ID included in event header or payload?
[ ] Is event processing context reconstructed on consume?

Tests
[ ] Are there tests for context propagation?
[ ] Are there tests for context cleanup?
[ ] Are there tests for cross-tenant leakage prevention?

If a value affects correctness, pass it explicitly.
If a value affects observability, propagate it consistently.
If a value affects security, validate it at the boundary.
If a value is stored in ThreadLocal, clear it deterministically.
If execution changes thread, assume context is lost until proven otherwise.

Anti-pattern: storing full request object in ThreadLocal
Risk: memory leak, lifecycle confusion, hidden dependency

Anti-pattern: domain logic reads tenant from static context
Risk: impossible-to-test tenant behavior and hidden cross-tenant bugs

Anti-pattern: async task uses request-scoped bean
Risk: context inactive or stale context

Anti-pattern: blindly forwarding all inbound headers
Risk: spoofed identity, tenant injection, data leak

Anti-pattern: using correlation ID as authorization proof
Risk: correlation is not identity

Anti-pattern: one log line at start and no context after async boundary
Risk: traceability disappears during actual work

[ ] standard inbound context creation
[ ] standard outbound context propagation
[ ] deterministic MDC/ThreadLocal cleanup
[ ] explicit tenant/security model
[ ] context-aware executor standard
[ ] Kafka/event context header standard
[ ] OpenTelemetry context propagation verified
[ ] tests for context propagation and cleanup
[ ] documented header/context contract
[ ] PR checklist for async boundary changes

- Request context is part of the runtime contract.
- ThreadLocal is powerful but dangerous in pooled-thread environments.
- MDC helps logs, but it must be propagated and cleared.
- SecurityContext is request-lifecycle-bound; do not treat it as durable identity.
- Tenant context must be explicit where correctness depends on it.
- Async boundary is a context boundary.
- HTTP and Kafka context propagation require governance.
- Broken context propagation creates silent production failures.