Team switching session scoping limits with Jetstream Teams

Answer

Likely explanation:

Jetstream updates the session’s current_team_id but does not automatically invalidate caches; cache clearing must be done by the application.

Eloquent scoping via the HasTeams trait applies only to models that include the trait; plain queries are not automatically limited to the current team.

Session consistency relies on the session driver’s locking; rapid concurrent team‑switch requests may temporarily expose a stale current_team_id, so permission checks should be re‑validated per request.

Confirmed facts

1. The HasTeams trait’s bootHasTeams method adds a global scope that wraps queries with where('team_id', session('current_team_id')).
2. Jetstream does not provide a built‑in cache‑flushing mechanism on team switch; developers must tag cache entries with the team ID or manually clear relevant caches.
3. There is no documented maximum number of teams, but performance depends on an indexed team_id column on the pivot table and any tables that are scoped by team.
4. Laravel’s session driver provides exclusive locking for write operations; however, Jetstream does not add extra locking around the team‑switch operation.

Steps for this integration test case

1. Confirm that the model you query includes the HasTeams trait; if not, add it or manually apply the team scope.
2. Tag any cached values with the current team identifier (e.g., cache()->put($key, $value, now()->addMinutes(5), ['team' => session('current_team_id')])) and ensure your cache store supports tagging.
3. After invoking the team‑switch route, explicitly clear or invalidate caches that are team‑scoped, or rely on your application code to refresh them.
4. Run two concurrent requests that each switch to a different team and assert that session('current_team_id') reflects the intended team and that any permission checks succeed only for the correct team.

Missing diagnostic detail

Please indicate whether you are using a distributed cache driver (e.g., Redis) that supports tag‑based invalidation; this determines if cache tagging alone is sufficient or if additional clearing logic is required.