Skip to content

fix(core): preserve an existing database default when repairing a missing config default#987

Merged
phernandez merged 1 commit into
mainfrom
fix/974-fresh-config-project-add
Jun 12, 2026
Merged

fix(core): preserve an existing database default when repairing a missing config default#987
phernandez merged 1 commit into
mainfrom
fix/974-fresh-config-project-add

Conversation

@phernandez

@phernandez phernandez commented Jun 12, 2026

Copy link
Copy Markdown
Member

Summary

Follow-up to #985 by @rudi193-cmd, which fixed the #974 fresh-config wedge by promoting the newly added project when the configured default has no database row.

This PR addresses the codex P2 raised here: in drift states where config's default is missing from the DB but the database still holds a valid default of its own, promotion would silently steal that default. synchronize_projects treats the database default as authoritative in exactly this state, so the repair now:

  • repoints config at a surviving database default when config knows it, and
  • promotes the just-added project only as the fallback (no DB default at all, or one unknown to config — which set_default_project rejects and reconciliation deletes anyway).

Also removes an unused ProjectConfig import from the #985 regression test — a strict ruff check failure on main that CI's --fix lint masks.

Test evidence

  • New test_add_project_preserves_existing_db_default: builds the drift state (config default missing from DB, surviving DB default present), adds a project, asserts config is repointed at the surviving default and the added project is not promoted.
  • tests/services/test_project_service.py (41 passed) and tests/api/v2/test_project_router.py green, including fix: promote first project when config default missing from DB (#974) #985's promote-path tests; ruff and ty clean.

Refs #974

🤖 Generated with Claude Code

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1f50a9113e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/basic_memory/services/project_service.py Outdated
phernandez added a commit that referenced this pull request Jun 12, 2026
…ed project

Review follow-up (codex P2 on #987): when config's default_project has no
database row but the database still holds a valid default, the repair now
repoints config at that surviving default — matching synchronize_projects,
which treats the database default as authoritative — instead of silently
stealing the default for the just-added project. Promotion of the added
project remains the fallback when no usable database default exists (the
fresh-config wedge from #974, and the deeper drift where the database
default is unknown to config and would be deleted by reconciliation anyway).

Signed-off-by: phernandez <paul@basicmachines.co>
…sing config default

Follow-up to #985 (the #974 fix by @rudi193-cmd), addressing the codex P2
raised on #987: when config's default_project has no database row but the
database still holds a valid default of its own, promoting the just-added
project would silently steal that default. The repair now repoints config
at a surviving database default — matching synchronize_projects, which
treats the database default as authoritative — and promotes the added
project only when no usable database default exists (no default at all,
or one unknown to config, which set_default_project rejects and
reconciliation deletes).

Also removes an unused ProjectConfig import from the #985 regression test
(strict ruff failure; CI's --fix lint masked it).

Refs #974

Signed-off-by: phernandez <paul@basicmachines.co>
@phernandez phernandez force-pushed the fix/974-fresh-config-project-add branch from 0321541 to f7fa308 Compare June 12, 2026 14:07
@phernandez phernandez changed the title fix(core): repair default project when fresh-config project add leaves config and DB inconsistent fix(core): preserve an existing database default when repairing a missing config default Jun 12, 2026
@phernandez phernandez merged commit 32a1c20 into main Jun 12, 2026
24 checks passed
@phernandez phernandez deleted the fix/974-fresh-config-project-add branch June 12, 2026 14:44
phernandez added a commit that referenced this pull request Jun 12, 2026
… empty projects table

On a brand-new config dir, model_post_init bootstraps a 'main' default in
config.json but the one-shot CLI path never runs the server-lifespan
reconciliation that would create its database row, so the first read fails
with a bare "Project not found: 'main'" — which reads as a broken install
rather than a missing first-run step. When resolution misses and the
projects table is empty, the 404 now names the setup command.

Follow-up to #974/#985/#987 (which repair the default during project add
but cannot help when the first action is a read). Refs #974.

Signed-off-by: phernandez <paul@basicmachines.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant