Remove the process-wide current-tenant account client
The legacy account client is a singleton with a mutable currentTenant field. Two overlapping requests can overwrite that field between authorization and the database query, selecting the wrong tenant's settings.
- Focused work estimate
- 3h 30m + prerequisites
- Priority in the scenario
- Urgent
- Engineering practice
- Tenant isolation · Concurrency · Dependency lifetimes
Estimated field mix
- Security50%
- Backend30%
- System design20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- SingletonRemove
Remove singleton-held tenant state while preserving safe shared connection infrastructure, using an interleaved request failure to justify the lifetime change.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional B2B scheduling service stores account settings in a legacy module whose database access leaks into HTTP handlers. A replacement must support existing clients and migration by tenant. Build a local modular application, a synthetic two-tenant dataset, and controllable old/new adapters; no baseline repository or fixtures are supplied. Keep the exercise in one application and local database, with no live customer traffic.
Setup prerequisites
- REST contracts
- Tenant authorization
- Transactions
- Dependency injection
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Remove mutable request or tenant context from the process-wide client and pass authorized scope explicitly into the service/repository boundary.
- Every account query constrains both tenant and account identity, including background lookups and the not-found path.
- Connection pooling may remain shared, but tests and request handlers cannot alter another operation's tenant context.
Implementation constraints
- Distinguish safe shared infrastructure lifetime from unsafe shared request state; replacing the singleton with a different global container is insufficient.
Verification to include
- Interleave two tenant requests with barriers at authorization and lookup; assert each receives only its own settings.
- Omit tenant scope and use a cross-tenant account identifier in direct service calls; verify rejection before data is returned.
Deliverables
- Explicit-scope account access change and deterministic overlap reproduction
Rollout and recovery
Block further migration until the scope checks pass; revert optional routing changes if needed while retaining the tenant-isolation fix.
Value of the work
For the engineer: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change.
For the team: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.