Checking tenant context when a worker processes alternating jobs

Goal

Test whether tenant-specific state carries into a later job handled by the same worker. This original fixture focuses on worker reuse and job ordering rather than broad tenant-isolation claims.

Prerequisites

Use an isolated worker process with synthetic tenants and distinguishable inert records. Provide a controlled way to send sequential jobs through the same worker and inspect their results without exposing real data.

Steps

1. Define each job’s explicit tenant input and permitted output. Include any application context expected to be initialized and cleared around processing, without relying on an implicit default tenant.

2. Run a job for the first tenant and then a job for the second tenant through the same worker. Check returned records and side effects against each job’s own expected tenant.

3. Reverse the job order and repeat. Order-sensitive differences warrant investigation into retained context, fixture contamination, or another hidden dependency; they are not automatically proof of a security defect.

4. Introduce a controlled failure in the first job before the second begins. Verify that cleanup and context initialization still yield the second job’s declared behavior.

5. After repair, retain alternating-order and failure-predecessor cases as regressions. Keep fresh-worker controls so the test can distinguish initialization defects from state left by an earlier job.

Expected result

The useful evidence maps predecessor job, current tenant, output, and side effects, making any dependence on prior tenant processing visible and reproducible.

Limits and test basis

This sequential proposal does not test simultaneous tasks or every form of shared state. Threaded, asynchronous, and multi-process execution require separately controlled concurrency fixtures with the same explicit tenant oracle. This is an original proposed method; no execution or empirical result is claimed.