Skip to content

warehouse: the connection registry is process-global, so one server hands the first project's connections to every project #1208

Description

@anandgupta42

What happens

ConnectionRegistry keeps configs, connectors, pending, and loaded as module-level state (packages/opencode/src/altimate/native/connections/registry.ts). ensureLoaded() loads once for the life of the process. One server process serving two projects therefore hands the first project's connections to both.

Reproduced with two Instance.provide() contexts against the same process:

first:   Instance.directory = .../project-a   →  path = .../project-a/warehouse.db
second:  Instance.directory = .../project-b   →  path = .../project-a/warehouse.db

Cached connectors make it worse: they are keyed only by connection name, so project B can be handed a live connector already open against project A's warehouse.

Why it matters now

This predates #1204 — before it, the base was the server's launch directory for everyone, so every project was equally wrong. #1204 made resolution correct for whichever project loads first, which is the right answer for the single-project case that covers nearly all real use. The residue is that the behaviour is now "first request wins" rather than "uniformly wrong", and that is worth closing properly rather than leaving in a comment.

Two related gaps in the same area:

  • Instance.directory is the request's working directory, not Instance.worktree. A request naming a nested directory looks for .altimate-code in that nested directory rather than at the project root.
  • run --attach without --dir sends no directory (cli/cmd/run.ts:408), so the server falls back to its own cwd (server/server.ts:281).

What a fix looks like

Make the registry state instance-scoped rather than module-scoped — keyed by Instance.directory, or held in the instance context — so each project loads and caches its own configs and connectors. Connector cache keys need the project in them too.

Not a blocker for #1204

#1204 documents this limitation in projectRoot()'s doc comment and does not regress it. Filing separately because the fix is a state-ownership change across the whole registry, not a path-resolution change.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions