Problem
It might be helpful to add some guardrails to the mm init wizard.
Currently, even if something goes wrong during the wizard, the setup flow may continue to the next steps. Continuing while silently ignoring a failed or missing intermediate step could potentially lead to confusing behavior or later issues.
To prevent this, it may be better if the wizard explicitly informs the user when a step fails, and then either forces the user back to the previous step or aborts the entire mm init wizard as failed.
In this particular case, the root cause appears to be unrelated to memtomem: the Ollama server is not working correctly. I have not yet identified why the Ollama server fails to start, but it seems clear that the failure itself is caused by something outside of memtomem.
1. Embedding Provider
(b: back, q: quit)
Choose how to generate embeddings:
[1] Quick start — keyword search only, no setup needed (recommended)
[2] Local ONNX — dense search, no server needed (pip install memtomem[onnx])
[3] Ollama — local dense embeddings, needs GPU
[4] OpenAI — cloud dense embeddings, needs API key
Select [1]: 3
Ollama not running. Starting 'ollama serve'...
Run 'ollama serve' in another terminal if this fails.
Available models:
[1] nomic-embed-text — English, fast (768d)
[2] bge-m3 — multilingual, higher accuracy (1024d)
Select [1]: 2
Model 'bge-m3' not found. Pull now? [Y/n]: Y
Pulling bge-m3... (this may take a few minutes)
Pull failed: 2026/05/01 03:37:58 WARN Failed to rotate log older=C:\Users\user\AppData\Local\Ollama\app-1.log newer=C:\Users\user\AppData\Local\Ollama\app.log error="rename C:\\Users\\user\\AppData\\Local\\Ollama\\app.log C:\\Users\\user\\AppData\\Local\\Ollama\\app-1.log: The process cannot access the file because it is being used by another process."
time=2026-05-01T03:37:58.901+09:00 level=INFO source=app_windows.go:282 msg="starting Ollama" app=C:\Users\user\AppData\Local\Programs\Ollama version=0.22.0 OS=Windows/10.0.19045
time=2026-05-01T03:37:58.902+09:00 level=INFO source=eventloop.go:309 msg="existing instance found, not focusing due to startHidden"
time=2026-05-01T03:37:58.902+09:00 level=INFO source=app_windows.go:79 msg="existing instance found, exiting"
Error: timed out waiting for server to start
You can pull manually: ollama pull bge-m3
2. Reranker (optional)
(b: back, q: quit)
Cross-encoder reranking sharpens search relevance after BM25+dense fusion.
Runs locally via fastembed ONNX — no API key, no server.
Enable reranker? [y/N]:
Looking at part of the wizard flow, during the “Available models” selection step, ollama list appears to be executed internally to retrieve the list of installed models. However, because the Ollama server is not working properly, the actual output is: Error: timed out waiting for server to start
The wizard seems to receive this output and interpret it as meaning that the selected model is not installed, so it then attempts to pull the model. (Even though the model is already pulled and installed.)
Although the root cause and the resulting issue are relatively minor, the current flow feels somewhat awkward because the wizard continues to the next step despite the failed operation. It would be better to make the flow stricter by enforcing a clear failure path for the user.
Proposed solution
I think the user experience would be better if guardrails were added so that, when a step fails during the wizard, the user is either returned to the previous step or the entire wizard is treated as failed and aborted.
Alternatives considered
No response
Additional context
No response
Problem
It might be helpful to add some guardrails to the
mm initwizard.Currently, even if something goes wrong during the wizard, the setup flow may continue to the next steps. Continuing while silently ignoring a failed or missing intermediate step could potentially lead to confusing behavior or later issues.
To prevent this, it may be better if the wizard explicitly informs the user when a step fails, and then either forces the user back to the previous step or aborts the entire
mm initwizard as failed.In this particular case, the root cause appears to be unrelated to
memtomem: the Ollama server is not working correctly. I have not yet identified why the Ollama server fails to start, but it seems clear that the failure itself is caused by something outside ofmemtomem.Looking at part of the wizard flow, during the “Available models” selection step,
ollama listappears to be executed internally to retrieve the list of installed models. However, because the Ollama server is not working properly, the actual output is:Error: timed out waiting for server to startThe wizard seems to receive this output and interpret it as meaning that the selected model is not installed, so it then attempts to pull the model. (Even though the model is already pulled and installed.)
Although the root cause and the resulting issue are relatively minor, the current flow feels somewhat awkward because the wizard continues to the next step despite the failed operation. It would be better to make the flow stricter by enforcing a clear failure path for the user.
Proposed solution
I think the user experience would be better if guardrails were added so that, when a step fails during the wizard, the user is either returned to the previous step or the entire wizard is treated as failed and aborted.
Alternatives considered
No response
Additional context
No response