Canonical dogfood report
The issue description was partially corrupted by shell interpolation while submitting Markdown. This comment is the authoritative report.
Running gitcode-mcp rag setup --yes with a live local Ollama provider and a missing qwen3-embedding:0.6b model produces no output while the model is downloading. After the provider request exceeds the configured 30-second timeout, the CLI reports:
status: model_pull_failed
pull_attempted: true
diagnostics: model pull failed: Post "http://127.0.0.1:11434/api/pull": context deadline exceeded
Ollama can continue and complete the pull after the client timeout. A subsequent gitcode-mcp rag setup then reports status: ready and embedding_smoke: ok. This makes a successful setup look failed and leaves the user without progress or a reliable next action.
Expected behavior
- Print an immediate, bounded progress/status line before a confirmed model download begins.
- Do not apply the ordinary 30-second provider probe timeout to a large model pull.
- If a pull request times out or disconnects, re-check model availability before declaring failure.
- On success, print the next repository-scoped commands, including that
rag status,rag index, andrag searchrequire--repo. - Keep JSON output machine-readable; progress should use a deliberate text/JSONL contract rather than corrupting the final JSON document.
Acceptance criteria
- A slow model pull does not become a false
model_pull_failedsolely because it exceeds the probe timeout. - Text mode shows that a model pull is in progress instead of remaining silent.
- A provider-side completion observed after a transport timeout is classified as ready.
- Tests cover slow/timeout pull recovery and progress notification.
- Documentation describes the interactive/non-interactive setup handoff.


Implementation progress
Implemented on codex/issue-106-rag-setup-pull in commit 8d6dee4 and opened MR !106.
The patch:
- separates model-download timeout from the short provider probe timeout, with a 30-minute minimum for confirmed pulls;
- emits an immediate text-mode
pulling modelhandoff; - re-checks provider model state after a pull transport error before classifying the setup as failed;
- prints repository-scoped next commands after setup becomes ready;
- preserves
--format jsonas one machine-readable document; - documents the setup-to-status/index/search handoff.
Verification: go test ./... and git diff --check pass. CI is being monitored separately.


Dogfood report\n\nRunning status: ready
profile: qwen3-ollama-0_6b-1024
provider: ollama
provider_type: ollama
endpoint: http://127.0.0.1:11434
executable: ollama
executable_path: /opt/homebrew/bin/ollama
provider_installed: true
provider_live: true
autostart: true
model: qwen3-embedding:0.6b
model_available: true
model_store_path: /Users/urandon/Library/Caches/gitcode-mcp/models
provider_model_env: OLLAMA_MODELS
pull_attempted: false
embedding_smoke: ok
install_instructions: Install Ollama from https://ollama.com/download. Set OLLAMA_MODELS or rag.providers.ollama.env.OLLAMA_MODELS to place provider-owned models on another disk. with a live local Ollama provider and a missing model produces no output while the model is downloading. After the provider request exceeds the configured 30 second timeout, the CLI reports:\n\n\n\nOllama can continue and complete the pull after the client timeout. A subsequent status: ready
profile: qwen3-ollama-0_6b-1024
provider: ollama
provider_type: ollama
endpoint: http://127.0.0.1:11434
executable: ollama
executable_path: /opt/homebrew/bin/ollama
provider_installed: true
provider_live: true
autostart: true
model: qwen3-embedding:0.6b
model_available: true
model_store_path: /Users/urandon/Library/Caches/gitcode-mcp/models
provider_model_env: OLLAMA_MODELS
pull_attempted: false
embedding_smoke: ok
install_instructions: Install Ollama from https://ollama.com/download. Set OLLAMA_MODELS or rag.providers.ollama.env.OLLAMA_MODELS to place provider-owned models on another disk. then reports and . This makes a successful setup look failed and leaves the user without progress or a reliable next action.\n\n## Expected behavior\n\n- Print an immediate, bounded progress/status line before a confirmed model download begins.\n- Do not apply the ordinary 30 second provider probe timeout to a large model pull.\n- If a pull request times out or disconnects, re-check model availability before declaring failure.\n- On success, print the next repository-scoped commands, including that , , and require .\n- Keep JSON output machine-readable; progress should use a deliberate text/JSONL contract rather than corrupting the final JSON document.\n\n## Acceptance criteria\n\n- A slow model pull does not become a false solely because it exceeds the probe timeout.\n- Text mode shows that a model pull is in progress instead of remaining silent.\n- A provider-side completion observed after a transport timeout is classified as ready.\n- Tests cover slow/timeout pull recovery and progress notification.\n- Documentation describes the interactive/non-interactive setup handoff.