Skip to main content

Troubleshooting Tenant Context

Summary​

This page covers the most common root cause behind asset symptoms: incorrect or missing tenant context. The service resolves tenant from forwarded headers and claims through an HTTP tenant context. All reads are scoped by EF global query filters to the current tenant, so an empty result almost always means the wrong or missing tenant context rather than absent data. When tenant context cannot be resolved, a middleware maps the resulting invalid-operation condition to an HTTP 400. Cross-tenant reads are prevented at the application level by these query filters, not by database row-level security.

Audience​

Support engineers and developers investigating empty lists, 400 responses on asset calls, or reports that data "disappeared" for one tenant while being visible in another context.

Symptoms​

  • An asset list or workspace projection returns empty when data is expected.
  • An asset call returns HTTP 400.
  • A record visible in one context is not visible in another.
  • A user reports that assets vanished after a context or session change.

Cause​

Scope​

This page covers tenant resolution from forwarded headers and claims and the effect of global query filters on reads. It does not cover authorization or gateway routing, which are handled separately.

Likely causes​

  • The tenant context is missing or unresolved, so a middleware maps the invalid-operation condition to HTTP 400.
  • The tenant context resolved to a different tenant than the data belongs to, so query filters return an empty or reduced result.
  • The request carried the wrong TenantId or TenantKey in its forwarded headers or claims.
  • The data genuinely does not exist for that tenant, which is the least common case and should be confirmed last.

Resolution​

Safe diagnostics​

  • Confirm the forwarded tenant identifiers on the request path resolve to the intended tenant.
  • Re-run the same read with the confirmed correct tenant context and compare the result set.
  • Treat an empty list as a tenant-context signal first; only conclude data is missing after tenant context is confirmed correct.
  • For a 400 on an asset call, check whether tenant context was present at all before looking at payload validation.

Validation​

  • Confirm the list is non-empty once the correct tenant context is applied, or that emptiness persists under a confirmed-correct tenant, which then indicates genuinely absent data.
  • Confirm 400 responses resolve once tenant context is present.
  • Confirm no cross-tenant leakage is observed, consistent with application-level query filters.

Evidence to Collect​

  • The tenant identifiers observed on the request.
  • The response status and whether the list was empty or reduced.
  • A correlation identifier and timestamp.
  • Which surface was read (native list, compatibility workspace projection).

Escalation​

Route unresolved tenant-resolution behavior to the asset or backend team. Route forwarded-header propagation issues to the gateway owner. Route schema-level tenancy questions to the database owner.

Source References​

  • microservices/src/asset-service/Infrastructure/AssetDbContext.cs
  • microservices/src/asset-service/Api/AssetEndpoints.cs
  • microservices/src/asset-service/Api/AssetCompatEndpoints.cs

See Also​

Keywords​

tenant context, query filters, empty list, multi-tenant, http 400

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly