Artifacts export files; tunnels forward traffic to a live sandbox port. They are separate
from persistent workspaces and application transactions. These reliability changes belong
to the reviewed 2.12.0 candidate, not every hosted deployment.
Artifact integrity and expiry
Retain artifact identity, source sandbox/path, size, SHA-256, expiry, and storage metadata.
Artifact retention is separate from sandbox lifetime. The candidate checks stored size/hash,
limits bytes before fetching, and rejects truncated/altered data before writing into a sandbox.
Expired or malformed expiry metadata prevents new download/signing/write dispatch. Metadata
inspection and authorized deletion remain available after expiry.
S3/GCS URL issuance is capped by artifact expiry and reports effective remaining lifetime.
Expiring Azure/local artifacts use managed downloads because their direct URL paths do not
enforce that deadline. Links are credentials; revocation cannot erase downloaded copies.
Deletion resolves the source sandbox and current permission. Unavailable/incomplete or
mismatched source evidence fails closed. CLI artifact mutations validate receipts without
adding generic retries around SDK operations.
Persist a private tunnel key
Persist the exact key and complete options before dispatch. idempotencyKey is client-only
and sent in the Idempotency-Key header. Keys contain 1–256 printable ASCII characters
without whitespace. Automatic key generation for one call does not give a restarted caller
the original key. Candidate CLI tunnel open accepts --idempotency-key and JSON receipts.
Keep explicit protocol/public values: omitted defaults and explicit fields can hash
differently. Stop/close success requires a positive acknowledgement, with eventual runtime
cleanup and in-flight work considered separately.
Replay conditions
Recovery requires the same principal, concrete path, sandbox, complete body, and unexpired
reservation (currently 24 hours). Permissions are checked again. Changed payload returns 409;
closed, expired, or unavailable matching records return 503 while retaining the reservation.
They do not expose a stale token or create a replacement.
Inspect listTunnels(sandboxId) before intentionally starting another operation. A session
helper resolves today’s sandbox, so it cannot replay a previous sandbox’s tunnel after a
rotation. Retain the original sandbox ID and use its direct tunnel method.
DB versus memory storage
TUNNEL_STORE_BACKEND=db uses shared PostgreSQL records/token hashes and migration 069.
Cross-replica duplicate protection also needs compatible DB-backed idempotency. Another
replica can forward/close after creator restart; active connections do not migrate. DB
failure is explicit rather than falling back to stale memory.
The candidate defaults to DB mode in production and memory in development. Retained hosted
inventory ends at migration 068. Coordinate memory-tunnel drain, schema/configuration,
original receipts, and hosted acceptance before switching stores.
Forwarding behavior
The candidate preserves compressed bytes, encoding/length headers, individual cookies and
manual redirects, while stripping connection-scoped headers. Disconnects/early responses
close unfinished upstream work. Upstream POST failures are not automatically replayed.
Private tokens, source ownership, TTL and access mode still apply.
Source: SDK tunnel guide, Node artifact/tunnel handlers/stores and October 20 release
records, checked at 67bc2370. Continue with
operations or
execution recovery. Last modified on October 20, 2026