Sequential SDK invocations can reuse a previous client's memoized token and cache identity, allowing one SDK instance to receive another instance's cached response.
Confirmed locally against e0fdee49a347255bbbb072dfc74baf53ae5998de through the public createSentrySDK API, using only synthetic credentials and a mocked HTTP boundary. Three clients share a config directory and request the same endpoint:
const first = createSentrySDK({ token: "synthetic-token-A", cwd });
const second = createSentrySDK({ token: "synthetic-token-B", cwd });
const malformed = createSentrySDK({ token: "synthetic\nbad-token", cwd });
await first.api({ endpoint });
await second.api({ endpoint });
await malformed.api({ endpoint });The mock returns an identity-specific body with Cache-Control: private, max-age=300 and Vary: Authorization. After the first cache write completes, all three calls return the first identity's body. There is exactly one HTTP request, authorized as the first client. The consumer's process.env remains unchanged. No concurrent calls are needed.
executeWithCapture and executeWithStream replace the environment for each invocation, but setEnv only replaces a reference. getAuthToken and getIdentityFingerprint retain their memoized values, which are then used by the response-cache lookup.
Expected: each invocation uses its own effective credential and cache identity. A selected malformed token must not reuse a previous client's identity. Review token, identity, and host-related state together at SDK invocation boundaries, including cleanup and streaming paths. Changing bearer formatting alone cannot fix stale identity selection.
Suggested regressions: sequential clients with distinct valid tokens, a malformed second token, per-client hosts/config directories, and cached versus uncached requests. Keep concurrent invocation behavior explicit rather than assuming cache resets alone make it safe.
Relevant files: packages/cli/src/lib/sdk-invoke.ts, packages/cli/src/lib/env.ts, packages/cli/src/lib/db/auth.ts, and packages/cli/src/lib/sentry-client.ts.
Sequential SDK invocations can reuse a previous client's memoized token and cache identity, allowing one SDK instance to receive another instance's cached response.
Confirmed locally against
e0fdee49a347255bbbb072dfc74baf53ae5998dethrough the publiccreateSentrySDKAPI, using only synthetic credentials and a mocked HTTP boundary. Three clients share a config directory and request the same endpoint:The mock returns an identity-specific body with
Cache-Control: private, max-age=300andVary: Authorization. After the first cache write completes, all three calls return the first identity's body. There is exactly one HTTP request, authorized as the first client. The consumer'sprocess.envremains unchanged. No concurrent calls are needed.executeWithCaptureandexecuteWithStreamreplace the environment for each invocation, butsetEnvonly replaces a reference.getAuthTokenandgetIdentityFingerprintretain their memoized values, which are then used by the response-cache lookup.Expected: each invocation uses its own effective credential and cache identity. A selected malformed token must not reuse a previous client's identity. Review token, identity, and host-related state together at SDK invocation boundaries, including cleanup and streaming paths. Changing bearer formatting alone cannot fix stale identity selection.
Suggested regressions: sequential clients with distinct valid tokens, a malformed second token, per-client hosts/config directories, and cached versus uncached requests. Keep concurrent invocation behavior explicit rather than assuming cache resets alone make it safe.
Relevant files:
packages/cli/src/lib/sdk-invoke.ts,packages/cli/src/lib/env.ts,packages/cli/src/lib/db/auth.ts, andpackages/cli/src/lib/sentry-client.ts.