overengineeringstudio / overengineeringstudio/effect-utils
notion db track silently appends to an existing workspace manifest (surprising sync . failure)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 82
- Forks
- 2
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 121
Description
Summary
notion db track appends a data source to an existing notion.workspace.v1.json with no warning. If a workspace is already tracked (or carries a leftover manifest), a second track silently produces a manifest with two data sources, after which notion db sync . fails with:
Workspace manifest in <dir> tracks multiple data sources; pass --sqlite <path>
The error is clean, typed, and actionable (it tells you to pass --sqlite), so this is not a data-loss bug — appending is the correct primitive for genuine multi-source workspaces. But the failure mode is surprising for the common single-source case: re-running track (or tracking into a dir with stale state) breaks the workspace-mode sync . with no signal at track time.
Discovered
While fixing the sqlite demo (#899): demo/sqlite/reset.sh wiped the stage but not notion.workspace.v1.json, so a re-run left two data sources and sync . broke. Worked around in the demo by removing the manifest in the wipe step (44e91413), but the underlying track ergonomics are worth addressing.
Proposal (pick one, non-blocking)
- At
tracktime, if the target workspace already tracks a different data source, emit a warning (or refuse behind a--add-source/--forceflag) rather than silently appending. - Or: when
sync .finds multiple data sources, name them in the error and suggest the specific--sqlite <path>values, so recovery doesn't require reading the manifest by hand.
Out-of-scope for #898/#899; filing so it isn't lost.
Posted on behalf of @schickling
| field | value |
|---|---|
agent_name |
💜 cl1-violet |
agent_session_id |
5ce468e2-a077-44ee-a724-bca1fb992e1c |
agent_tool |
Claude Code |
agent_tool_version |
2.1.202 |
agent_runtime |
Claude Code 2.1.202 |
agent_model |
claude-opus-4-8 |
runtime_profile |
/nix/store/34v4ljmkjh4sgzax68wwgggmzf69zmfk-coding-agent-runtime-profile/share/coding-agents/profile.json |
skills_manifest |
/nix/store/92pwq9mx1byj8nl9an05dyh4baykvf1d-agent-skills-corpus/share/agent-skills/manifest.json |
worktree |
effect-utils/schickling/2026-07-07-notion-demo |
machine |
mbp2025 |
tooling_profile |
dotfiles@unknown |
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the sequence described with notion db track and notion db sync ., then inspect the manifest handling around notion.workspace.v1.json. Review demo/sqlite/reset.sh for the stale-manifest scenario and choose one proposal: warn or require an explicit opt-in when tracking a different source, or improve the multi-source sync error with source paths. Done means the chosen behavior is covered and the single-source sync flow no longer fails silently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100