rag initialization failure

[k33g]

Description

If I define a "rag" section in the configuration file, the first time at launch that I do a search, I would get this error message.

Some toolsets failed to initialize for agent 'cookbook'.

Details:

- toolset rag failed: failed to create RAG manager: failed to build strategy configs for RAG "rag_knowledge": failed to build strategy "chunked-embeddings" for RAG "rag_knowledge": failed to create database: failed to create schema: attempt to write a readonly database (1032)

If I quit the Docker agent and restart it, it works.

I use Docker Agent v1.141.0

Expected Behavior

No response

Actual Behavior

No response

Steps to Reproduce

the rag section:

rag:
  rag_knowledge:
    tool:
      description: >
        Search the Go and htmx cookbook.
        Every topic comes with its common mistakes and how to avoid them.
    docs:
      - ./knowledge

    strategies:
      - type: chunked-embeddings
        embedding_model: embedder
        database: ./knowledge-embeddings.db
        vector_dimensions: 768
        similarity_metric: cosine_similarity
        threshold: 0.3
        limit: 6
        chunking:
          size: 1200
          overlap: 100
          respect_word_boundaries: true

models:
  embedder:
    provider: dmr
    model: huggingface.co/unsloth/embeddinggemma-300m-gguf:Q8_0
    base_url: http://host.docker.internal:12434/engines/v1
    max_tokens: 2048

Docker Agent version

1.141.0

OS & terminal

Linux inside SBX

Model used

Local model

Error output

Some toolsets failed to initialize for agent 'cookbook'.

Details:

- toolset rag failed: failed to create RAG manager: failed to build strategy configs for RAG "rag_knowledge": failed to build strategy "chunked-embeddings" for RAG "rag_knowledge": failed to create database: failed to create schema: attempt to write a readonly database (1032)

Screenshots

No response

Additional context

No response

[20csm2k25-netizen]

Issue #4364
This is genuinely valuable even without a fix — it saves whoever picks this up from re-treading the same investigation path.
I traced this to narrow down where the failure actually happens, in case it helps whoever has sandbox access to reproduce it directly.
Failure point: newChunkedVectorDB in pkg/rag/strategy/chunked_embeddings_database.go opens via sqliteutil.OpenDB (which does MkdirAll → sql.Open → SetMaxOpenConns(1) → PingContext, and that succeeds), then immediately calls createSchema, which is where CREATE TABLE fails with SQLITE_READONLY. So the connection opens and pings fine — the failure is specifically on the first write statement against a brand-new file.
Ruled out:
Not a double-construction/concurrent-open race — rag.NewManager → buildStrategyConfigs → strategy.BuildStrategy → NewChunkedEmbeddingsFromConfig → newChunkedVectorDB is a single call chain with one call site (pkg/tools/builtin/rag/rag.go's CreateToolSet), called once at toolset creation.
Not a bare modernc.org/sqlite v1.59.0 bug I reproduced the exact open/ping/create-table sequence from sqliteutil.OpenDB in isolation (fresh temp dir, fresh file, both WAL and DELETE journal modes, sequential "first-launch then restart" opens against the same path) and it succeeded every time on a plain Linux filesystem.
Leading theory: pkg/sqliteutil/sqlite.go's journalMode() has an existing comment noting that WAL relies on a shared-memory index (-shm) that's incoherent across the VM boundary when the data dir is bind-mounted via virtiofs inside Docker's sandbox which is explicitly why sandboxed runs use DELETE journal mode instead of WAL. Given the reporter's OS is "Linux inside SBX" (Docker Agent's sandbox), this looks like the same class of virtiofs/mount-timing issue, possibly specific to how the RAG database's directory/file gets created relative to when the sandbox's mount is fully ready but I wasn't able to reproduce a virtiofs-backed mount locally to confirm.
Since I can't replicate the actual sandbox VM boundary outside Docker Desktop, I don't have a confirmed fix to propose yet, but hopefully this narrows the search space for someone who does.