Repository navigation
VScode extension lineage bug with multiple projects #5618
Description
Description
pip install sqlmesh[lsp]==0.224.0
When using the options for multiple projects introduced in #5084 the lineage view gives an error like
Error: '~/nested/project_1/models/seed_model.sql' is not in the subpath of '~/nested/project_2'
The other LSP features are working as expected with respect to e.g. finding definitions.
I suspect that the issue stems from this line in the Web API server, where it tries to take context.path relative to model._path. I believe that in the multi project setup, context.path will resolve to the last loaded project which is not necessarily relative to the current model path.
Example to reproduce bug
Setup two projects in a nested sub folder e.g.
.
└── root/
└── nested/
├── project_1/
│ ├── ...
│ └── config.yaml
└── project_2/
├── ...
└── config.yaml
Ensure that both have different projects, but same gateway. You can setup the projects with sqlmesh init duckdb and edit the config.yaml files
Open VSCode and set workspace path to be at root/. Open settings (either UI or settings.json) and add either relative paths (./nested/project_1, ./nested/project_2) or absolute paths to the "sqlmesh.projectPaths" vscode extension variable
Open a model in project_1 and verify that e.g. go to definition part of extension still works
Open lineage panel and you should get an error like Error: '~/nested/project_1/models/seed_model.sql' is not in the subpath of '~/nested/project_2'
I would be happy to make a contribution to fix this if I could be pointed in the right direction as to how to solve it, as I am not that familiar with the Webserver API part of the project
Activity
MisterWheatley commentedon Dec 10, 2025
The following is my best guess at the underlying logic of the problem, copied from slack thread
web.server.api.endpoints.models.get_modelsin this lineget_modelscall serializes models based on passedContextobject and tries to set a path relative toContext.pathin this lineContext.pathattribute is not guarenteed to be relative tomodel._pathin a multi repo contextContext.pathattribute is set in this line and is simply the first element fromContext.configsMisterWheatley commentedon Dec 10, 2025
Another minimal example to reproduce the underlying bug/issue: (copied from slack thread aswell)
Setup/requirements
pip install sqlmesh[web]Navigate to
sqlmesh/examples/multiGives a ValueError from pathlib with the following message:
sqlmesh/examples/multi/repo_2/models/c.sql is not in the subpath of sqlmesh/example/multi/repo_1By swapping the order of paths you instead get:
sqlmesh/examples/multi/repo_1/models/b.sql is not in the subpath of sqlmesh/examples/multi/repo_2I.e. the web.server.api.endpoints.models.get_modelsmethod cannot handle a multi project context as it currently is
tripleaceme commentedon Sep 11, 2026
I've opened #6052 for this.
@MisterWheatley your diagnosis was spot on.
Context.__init__setsself.pathfromnext(iter(self.configs.items())), so it's only the first project and isn't an ancestor of the models in any of the others — which is why go-to-definition kept working while only the lineage panel failed.The PR resolves each model against whichever configured root actually contains it (deepest match wins, for nested projects), reusing the existing
web.server.utils.is_relative_tohelper, and falls back to the absolute path for a model that lives outside every configured root rather than raising. Single-project behaviour is unchanged.There's a regression test using
examples/multi/repo_1+repo_2that reproduces the exactValueErroronmainand passes with the fix.tripleaceme commentedon Sep 24, 2026
This looks safe to close — #6052 merged on 12 Sep and fixes it. The PR body had no
Fixes #5618keyword, so GitHub never closed this automatically and it still reads as open, unassigned work.serialize_modelnow resolves each model's path against its own project root rather thancontext.path, which was only ever the first of the configured projects.