Summary
This PR adds Temporal scenario coverage to the on-prem test harness, including an end-to-end auth-refresh validation path for a seeded Gmail connected account.
What Changed
- Added a dedicated Temporal scenario test file and wired it into scenario execution.
- Updated scenario registry for
temporal-installation:
- uses a dedicated namespace/release (
composio-temporal)
- includes explicit test path wiring
- resets namespace before install for isolation
- Extended seeded fixture config support with Gmail connected-account identifiers.
- Added a Temporal-only auth-refresh test flow in the shared integration suite:
- verifies seeded Gmail tool execution succeeds initially
- intentionally invalidates the connected account
access_token
- waits for Temporal auth-refresh to recover the connection
- retries every 30s, up to 20 minutes
- Added Gmail seeded IDs in local test config for harness/dev consistency.
Why
temporal-installation previously did not have parity with the main scenario validations. This PR brings it in line with common scenario tests and adds direct regression protection for auth-refresh behavior, which is one of Temporal’s critical responsibilities.
Auth-Refresh Test Behavior
- Tool used to validate connection health:
GMAIL_FETCH_EMAILS
- Invalidation method: decrypt seeded
connected_accounts.dataTypedEncrypted, mutate token, re-encrypt, persist
- Recovery criteria: Gmail tool execution succeeds again using the same seeded connected account
- Polling strategy: 30-second interval with a 20-minute timeout
Validation
Notes
- Auth refresh scheduling cadence in Thermos defaults to 15 minutes (with jitter), so the 20-minute timeout is intentional to avoid flakiness.
- The auth-refresh path is scoped to
temporal-installation only; other scenarios continue to run the shared/common suite without this Temporal-specific check.
@utkarsh-dixitchecks…temporal-auth-refresh-scenario-tests → main13 files · +798 −18updated 3w ago