A stats assertion caught 17 visits that belonged to other organizations

The helper does three things in order. It calls context.switchToHttp(), takes the Express request, and returns request.user.organizationId when that is set ^[10]. When it is not, it calls context.switchToRpc().getData() and looks for organizationId on the payload; the comment above that branch labels it a fallback for non-HTTP contexts such as cron jobs ^[11]. When both miss, it throws Error('Organization ID not found in context') ^[12].

The throw is the good part. The first attempt's failure mode was a tenant id of undefined, produced because some controllers used @Req() and others read the ExecutionContext directly ^[7].

I would ask a question about the RPC fallback at review. getOrganizationId takes exactly one parameter, an ExecutionContext ^[10]. A cron tick does not arrive with one, so something has to construct an object whose switchToRpc().getData() returns an organizationId before a queue worker can call this at all ^[19]. The diffs in the walkthrough cover construction.controller.ts and the opening of virtual-tour.service.ts, and no background-job call site is among them ^[20]. Background jobs were the third of three reasons given for abandoning the guard ^[21].

construction.controller.ts, described as the biggest file in Phase 4, gains @Context() ctx: ExecutionContext and keeps @Req() req: Request, with the body swapping req.user.organizationId for TenantContext.getOrganizationId(ctx) ^[14]. The post says the injection is there "to keep the method signature identical for testing" ^[15]. The signature in the diff has one parameter more than before, and the Request the boilerplate complaint was about is still in it ^[14][8].

The expected payload had organizationId and visits; the received payload had both of those, correct, plus otherOrgVisits: 17 ^[3]. That is one field more than the test expected ^[18]. Nothing errored, and a client that ignores unknown fields would take a 200 and a superset. Both the privacy failure and the performance regressions came from the same place, most controllers running raw database queries with no organization_id filter ^[4][1].

Every service method that touches the database now takes organizationId as its first argument ^[16], and controllers pass it down explicitly ^[17]. I would normally push that filter under the query layer so that a new call site cannot forget it. The constraint arguing against that sits in the post's own diagnosis: global services such as whatsapp-ai.service.ts share the codebase with tenant-specific logic, which is what made runtime enforcement impossible in the first place ^[5]. A default filter under the ORM would need a documented escape hatch for the services meant to read across organizations. Given that mix, threading the argument through the construction, brokers and stats modules is the trade-off I would make too ^[2].