forked from molecule-ai/molecule-core
After #2710 + #2714 + the MOLECULE_STAGING_MINIMAX_API_KEY repo secret landed (2026-05-04 08:37Z), the next dispatched canary (run 25309323698) cleared every previous failure point but timed out at step 8/11 with `curl: (28) Operation timed out after 30002 ms`. The canary creates a fresh org per run, so every A2A POST hits a cold workspace + cold MiniMax endpoint: workspace boot → claude-code adapter starts event loop → first prompt ships → TLS handshake to api.minimax.io → cold model warmup → first-token generation Cold-call P95 lands around 25-30s on MiniMax-M2.7-highspeed; the 30-second `CURL_COMMON --max-time` is right on the edge and the run that timed out was 30.002s of zero bytes received. Fix: override `--max-time` for the canary's A2A POST only — 90s gives ~3x headroom. Subsequent A2A turns to the same workspace are sub-second, so this only widens step 8 of the canary's first turn. The shared CURL_COMMON timeout stays at 30s for everything else (provision, register, terminal, peers, teardown), where 30s is right. Verifies the rest of the canary script (provision, DNS, terminal-EIC, A2A round-trip) is platform-correct and the only operational gap is this latency knob. |
||
|---|---|---|
| .. | ||
| lib | ||
| _extract_token.py | ||
| _lib.sh | ||
| STAGING_SAAS_E2E.md | ||
| test_2307_peer_visibility_staging.sh | ||
| test_a2a_e2e.sh | ||
| test_activity_e2e.sh | ||
| test_api.sh | ||
| test_chat_attachments_e2e.sh | ||
| test_chat_attachments_multiruntime_e2e.sh | ||
| test_chat_upload_e2e.sh | ||
| test_claude_code_e2e.sh | ||
| test_comprehensive_e2e.sh | ||
| test_dev_mode.sh | ||
| test_harness_rc_normalization.sh | ||
| test_model_slug.sh | ||
| test_notify_attachments_e2e.sh | ||
| test_poll_mode_e2e.sh | ||
| test_priority_runtimes_e2e.sh | ||
| test_saas_tenant.sh | ||
| test_secrets_dispatch.sh | ||
| test_staging_external_runtime.sh | ||
| test_staging_full_saas.sh | ||