[stefanmirkovic]

Why

With the multi-tenancy extension every tenant has its own dead-letter queue and event store. The client only saw the default tenant: it listed, counted and changed dead letters of that tenant alone, and entity inspection could not find an entity that lives in a tenant. Platform side: AxonIQ/axoniq-platform#1047.

What changes

Tenancy

• PlatformTenancy lists the tenants, binds a processing context to one tenant and reads per-tenant positions from a multi-tenant tracking token. It is free of multi-tenancy types and only active when axoniq-multi-tenancy is on the classpath, which the client takes as an optional provided dependency.
• Outside message handling the framework resolves the tenant only from the processing context, so every call on a tenant-routed component runs in a unit of work from the configured UnitOfWorkFactory, bound to its tenant.

Dead letters

• Every DLQ route takes an optional tenant. Without one, listing pages across all tenants and uses cached per-tenant sizes to load only the tenants that cover the requested page; process and delete find the tenant that holds the letters.
• Each returned letter carries its tenant.
• The processor report counts dead letters per tenant (dlqSizePerTenant), cached for 30 seconds. A change through this node drops the cache on this node only.

Positions

• The processor report lists each segment's position per tenant (tenantPositions), read from the multi-tenant tracking token. position stays their sum.

Entity inspection

• Model inspection takes an optional tenant and otherwise looks for the entity in each tenant.

Versions

• Axoniq Framework 5.3.2 → 5.4.0: tenant-aware dead-letter processing needs process(filter, context), which 5.3 does not have.
• Dev version 5.4.4-SNAPSHOT.

Applications without multi-tenancy see no difference: no tenant on the routes, no per-tenant fields in the report.

Testing

• DeadLetterManager: listing per tenant and across tenants, paging over tenant boundaries, the size cache and its invalidation, process and delete in the tenant that holds the letter, a sequence id that exists in two tenants (refused unless a tenant is named), one unit of work per tenant, and the single-tenant path unchanged. ProcessorReportCreator: positions per tenant next to their sum. The DLQ responder integration test covers the new payloads.
• 222 tests green. The surefire config keeps axoniq-multi-tenancy off the test classpath, because it switches itself on and then needs Axon Server; tests opt in explicitly.
• Verified end to end with a two-tenant demo application against a local Platform running AxonIQ/axoniq-platform#1047: DLQ per tenant and for all tenants, retry, delete and retry all per tenant, segment positions per tenant, entity lookup per tenant and across tenants with paging over 16,000 events.

Not covered

Workflow inspection (#196) reads the event store without a tenant, so in a multi-tenant application it fails with "Tenant could not be resolved from the processing context". That needs its own change once #196 is merged.