feat(setup): warm the uv runtime before first server launch - #136
Merged
Merged
Conversation
yjouini
marked this pull request as ready for review
August 27, 2026 12:19
The host gives up on an MCP server that is still downloading dependencies on its first launch, which is the most common cause of a plugin that never becomes available after install. Warm the runtime during setup instead. Measured on a throwaway UV_CACHE_DIR, time to answer MCP initialize: no warm-up 6.36s after `uv sync --locked --script` 2.80s after one run with stdin closed 0.65s `uv sync --script` caches the downloads but leaves the environment to be created on first launch, so the skill uses a single run-and-exit instead and says explicitly not to substitute sync. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pmasiphelps
force-pushed
the
feat/prewarm-setup-runtime
branch
from
September 3, 2026 22:18
26d6f28 to
67ec438
Compare
pmasiphelps
self-requested a review
September 3, 2026 22:18
pmasiphelps
approved these changes
Sep 3, 2026
pmasiphelps
left a comment
Collaborator
There was a problem hiding this comment.
looks good! i made a slight change to the wording of the run_mcp relative path....codex complained about the previous wording. totally fine if you don't like the new wording. approved either way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a runtime warm-up step to the
dataiku-headless-setupskill added in #129. The host gives up on an MCP server that is still downloading dependencies on its first launch, which is the most common cause of a plugin that appears installed but never becomes available — the "restart Codex / still initializing" reports in #ask-dataiku-headless.The new step 5 runs the server once with stdin closed so it exits immediately, populating the uv cache and the script environment before the host ever launches it. Subsequent steps are renumbered; the frontmatter description now mentions the warm-up.
Why run-and-exit rather than
uv syncuv sync --locked --scriptlooks like the natural fit but only gets partway. Measured on this branch with a throwawayUV_CACHE_DIR(so the real cache was untouched), timing a full MCPinitializeround-trip againstbin/run_mcp.py:uv sync --scriptcaches the downloads but leaves the environment to be created on first launch, so the host still sees a slow first start. The skill therefore uses the run-and-exit form and says explicitly not to substitute sync. A cold cache for this script is ~148 MB, so on a slow or proxied network the 6.36s figure is a floor, not a typical case.