On self-hosted Retool 4.0.4-stable (Kubernetes, Helm chart 6.11.4) connected to Temporal Cloud (mTLS), the app-builder agent worker SERVICE_TYPE=R2_AGENT_TEMPORAL_WORKER crashloops on startup and can't open its Temporal connection:
[process service types] R2_AGENT_TEMPORAL_WORKER
creating temporal worker connection
TransportError: Failed to call GetSystemInfo: status: Unknown, message: "transport error"
at NativeConnection.connect (@temporalio/worker@1.11.6/lib/connection.js:58)
This blocks the Updated App Builder (beta) — app generation returns 504 {"error":"websocket_url_timeout"}.
What makes this odd: every other Temporal worker connects to the same Temporal Cloud endpoint with identical config (same TLS cert/key env, same host, same namespace, TLS_ENABLED=true, same node):
Worker (SERVICE_TYPE)
Result
workflow worker
connects, processing
AGENT_TEMPORAL_WORKER
1/1, "Worker started"
AGENT_EVAL_TEMPORAL_WORKER
1/1
R2_AGENT_TEMPORAL_WORKER
crashloop (GetSystemInfo transport error)
So Temporal Cloud, mTLS certs, DNS, and egress are all fine — only R2_AGENT_TEMPORAL_WORKER fails, at the transport layer during GetSystemInfo (first RPC, before any namespace/task-queue logic). Full Agents setup is done (agents.enabled=true, org AI/Agents on, provider configured) — the two product agent workers are healthy; only the app-builder (r2) worker fails.
Questions:
Known issue with R2_AGENT_TEMPORAL_WORKER on 4.0.x self-hosted + Temporal Cloud? Which release fixes it?
Does it establish its Temporal/TLS connection differently from AGENT_TEMPORAL_WORKER / the workflow worker?
Any r2-specific config we're missing beyond standard Temporal env + agents.enabled?
Update after further testing — it's the Temporal Cloud path specifically.
1. Still broken on the latest stable. Reproduced on 4.0.6-stable (Helm chart 6.11.10), not just 4.0.4 — same GetSystemInfo: transport error. So upgrading (image or chart) does not fix it; the r2/agent Temporal wiring is identical between 6.11.4 and 6.11.10.
2. Controlled repro isolating the one variable. I cloned the workingagent-worker deployment and changed onlySERVICE_TYPE → R2_AGENT_TEMPORAL_WORKER (identical image, mTLS certs, env, node) → it reproduces the crash. So it's the service-type code path, not environment.
3. The same r2 worker binary connects fine to a plaintext Temporal. Pointed the identical r2 worker at an in-cluster dev Temporal (temporal server start-dev, no TLS) → it reaches Worker state changed → RUNNING and polls the r2-agent queue normally. So the failure is specific to the Temporal Cloud mTLS/TLS handshake for this worker type.
4. Adding WORKFLOW_TEMPORAL_SERVER_NAME_OVERRIDE (SNI) did not help — still transport error.
5. Every other worker connects to the same Temporal Cloud namespace fine — WORKFLOW_TEMPORAL_WORKER, AGENT_TEMPORAL_WORKER, and AGENT_EVAL_TEMPORAL_WORKER are all RUNNING with the identical TLS env (and none of them need SNI/root-CA overrides). Only R2_AGENT_TEMPORAL_WORKER fails.
Net: this is your recommended production configuration — latest stable + Temporal Cloud — with the new App Builder's worker unable to connect, while all sibling workers can. It looks like R2_AGENT_TEMPORAL_WORKER constructs its native (@temporalio/worker v1.11.6) TLS/mTLS connection differently from AGENT_TEMPORAL_WORKER.
Questions: (a) Can you reproduce on 4.0.6 + Temporal Cloud? (b) Does the r2 worker read a different Temporal TLS config path than the other workers? Happy to share full logs.
Welcome to the community, @marcio_ide! Thanks for reaching out.
The primary difference between this worker and the others is the fact that it connects to a different Temporal namespace and, as such, references a separate set of RETOOL_INTERNAL_TEMPORAL_* environment variables. We recently added a fallback to the WORKFLOW_TEMPORAL_* set of variables that should go go live with the 4.0.7-stable release!
connects, processing
crashloop (