Skip to content

fix(notebooks): fall back to SITE_URL for sandbox callback URLs in prod#73018

Draft
sinan-ku wants to merge 1 commit into
masterfrom
fix/notebooks-sandbox-site-url-fallback
Draft

fix(notebooks): fall back to SITE_URL for sandbox callback URLs in prod#73018
sinan-ku wants to merge 1 commit into
masterfrom
fix/notebooks-sandbox-site-url-fallback

Conversation

@sinan-ku

Copy link
Copy Markdown
Contributor

Problem

Kernel-lane SQLV2 notebook runs (python/duckdb) never complete outside local dev. The sandbox is handed its callback and data-plane base URL by _backend_base_url(), which falls back to http://host.docker.internal:8000 whenever SANDBOX_API_URL is unset. That's a dev-only Docker alias, unreachable from a remote sandbox, so the kernel executes the code but can never POST the result envelope back to /internal/notebooks/runs/<run_id>/result/ (or reach the data plane). The run row stays RUNNING forever and the node spins indefinitely, even for a trivial print(1+2).

Changes

_backend_base_url() now resolves in order:

  1. SANDBOX_API_URL if set (e.g. an ngrok tunnel for driving a Modal sandbox from local dev)
  2. http://host.docker.internal:8000 under DEBUG (the local kernel runs in Docker, where SITE_URL would be an unreachable localhost)
  3. SITE_URL otherwise

This matches how the tasks product resolves its sandbox API URL (SANDBOX_API_URL or SITE_URL), with the extra dev branch because notebooks' local kernel lives in a Docker container.

How did you test this code?

Added TestSQLV2BackendBaseURL (parameterized SimpleTestCase, no DB) covering the three branches through build_callback_url. It catches the regression that shipped: a deployed environment without SANDBOX_API_URL handing the sandbox a dev-only unreachable URL - no existing test exercised these URL builders. Ran locally: 3 passed.

Automatic notifications

  • Publish to changelog?
  • Alert Sales and Marketing teams?

Docs update

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Authored with Claude Code. Skills invoked: /writing-tests. Root cause was diagnosed in an earlier session by tracing prod run rows and service logs: stuck-running kernel runs with zero requests ever hitting the callback or data-plane endpoints, pointing at the unreachable fallback URL. Considered fixing this purely via deployment env (SANDBOX_API_URL on the worker fleet) but the code-side SITE_URL fallback works with no deploy coordination and mirrors the existing tasks sandbox behavior; the env override remains available on top.

The SQLV2 kernel sandbox was handed http://host.docker.internal:8000 as its
callback and data-plane base URL whenever SANDBOX_API_URL was unset — a
dev-only Docker alias that is unreachable from a remote sandbox, so kernel-lane
runs never delivered their result envelope and stayed RUNNING forever.

Keep the host.docker.internal fallback for DEBUG (the kernel runs in local
Docker, where SITE_URL would be an unreachable localhost) and fall back to
SITE_URL otherwise, matching the tasks sandbox URL resolution.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@trunk-io

trunk-io Bot commented Jul 22, 2026

Copy link
Copy Markdown

Merging to master in this repository is managed by Trunk.

  • To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant