Closes a 4+ cycle Canvas tabs E2E flake pattern that's been blocking staging→main PRs since 2026-04-24+ (#2096, #2094, #2055, #2079, ...). Root cause: TLS_TIMEOUT_MS=180s (3 min) is too tight for the layered realities of staging tenant TLS readiness: 1. Cloudflare DNS propagation through the edge (1-2 min typical) 2. Tenant CF Tunnel registering the new hostname (1-2 min) 3. CF edge ACME cert provisioning + cache (1-3 min) Each layer can add 1-3 min on its own under heavy staging load — the realistic worst case is well past the 3-min cap. Provision and workspace-online timeouts were already raised to 20 min (staging-setup.ts:42-46 history). The TLS gate was the remaining under-budgeted step. Bumping to 10 min keeps it inside the 20-min PROVISION envelope so a genuinely-stuck tenant still fails loud at the earlier provision step rather than masquerading as a TLS issue. Both call sites raised together: - canvas/e2e/staging-setup.ts: TLS_TIMEOUT_MS = 10 * 60 * 1000 - tests/e2e/test_staging_full_saas.sh: TLS_DEADLINE += 600 Each carries an inline rationale comment so the next reviewer sees the layer-by-layer decomposition without re-reading the issue thread. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| _extract_token.py | ||
| _lib.sh | ||
| STAGING_SAAS_E2E.md | ||
| test_a2a_e2e.sh | ||
| test_activity_e2e.sh | ||
| test_api.sh | ||
| test_claude_code_e2e.sh | ||
| test_comprehensive_e2e.sh | ||
| test_dev_mode.sh | ||
| test_saas_tenant.sh | ||
| test_staging_full_saas.sh | ||