Vue 3 Composables and Mock Service Worker: Token Refresh Interception in Integration Tests

Testing Authenticated API Flows Across Component and Network Boundaries

When validating a Vue 3 application that relies on composables for authentication state and token refresh logic, the integration boundary between unit-tested composables and end-to-end network mocks becomes critical. The goal is to verify that expired access tokens trigger a transparent refresh request before the original API call retries, all without involving production credentials.

Current tooling allows mocking either at the composable level (via Vitest and Vue Test Utils) or at the network level (via Mock Service Worker in Cypress or Playwright). However, the interaction between a composable's internal refresh promise and MSW's request interception handlers is not explicitly documented. Specifically, it is unclear whether MSW can observe and respond to the second request issued after a token refresh when the first request fails with a 401, or whether the composable's retry logic executes entirely within the test's microtask queue before MSW evaluates the next handler.

Open Questions

1. Does MSW's onRequest callback fire for the retried request after a composable-driven token refresh, or is the retry swallowed by the test runner's event loop?
2. Can a single MSW handler sequence express "fail once with 401, then succeed with new token" without coupling to the composable's internal retry count?
3. What is the recommended pattern for asserting that the refresh endpoint was called exactly once before the original request succeeds?