Update websocket-tunnel example to use quick tunnels#700
Conversation
|
| const tunnel = await sandbox.tunnels.get(WS_PORT); | ||
| if (!tunnel) { | ||
| return new Response( | ||
| 'Unable to create Cloudflare Tunnel. Note, if you are running Cloudflare WARP you will need to disable WARP to access the tunnel in local development.', | ||
| { status: 500 } | ||
| ); | ||
| } |
There was a problem hiding this comment.
🟡 Friendly tunnel error message is unreachable dead code because tunnels.get() throws instead of returning null
The TunnelsHandler.get() method (packages/sandbox/src/tunnels/tunnels-handler.ts:137) is typed as Promise<TunnelInfo> (not nullable) and its implementation always either returns a valid TunnelInfo or throws an error. Therefore the if (!tunnel) guard at examples/websocket-tunnel/src/index.ts:26 is dead code — if tunnel creation fails (e.g. due to WARP interference), the thrown error propagates as an unhandled exception and the user sees a generic 500, never the helpful WARP diagnostic message. The code should use a try/catch around sandbox.tunnels.get(WS_PORT) instead of a nullish check.
| const tunnel = await sandbox.tunnels.get(WS_PORT); | |
| if (!tunnel) { | |
| return new Response( | |
| 'Unable to create Cloudflare Tunnel. Note, if you are running Cloudflare WARP you will need to disable WARP to access the tunnel in local development.', | |
| { status: 500 } | |
| ); | |
| } | |
| let tunnel: Awaited<ReturnType<typeof sandbox.tunnels.get>>; | |
| try { | |
| tunnel = await sandbox.tunnels.get(WS_PORT); | |
| } catch { | |
| return new Response( | |
| 'Unable to create Cloudflare Tunnel. Note, if you are running Cloudflare WARP you will need to disable WARP to access the tunnel in local development.', | |
| { status: 500 } | |
| ); | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
actually, this is a good point
| "vars": { | ||
| "SANDBOX_TRANSPORT": "rpc" | ||
| }, | ||
| "compatibility_date": "2026-04-22", |
There was a problem hiding this comment.
wrangler.jsonc uses 2026-04-22, but our types header says 2026-10-06? is that right? also did we go bcak to prev compat date?
i think we just need a fresh wrangler types, unless this is intentional
This currently depends on a fix to ensure that
sandbox.getProcess()returnsnullwhen using the RPC transport. Currently it incorrectly throws.