overengineeringstudio / overengineeringstudio/effect-utils

mr store fix can report clean state while mr lock still fails with StoreHygieneError

Open
#433 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

origin:agent type:agent-tooling type:bug
Dominant language
TypeScript
Stars
82
Forks
2
Avg merge
1d 8h
Merged PRs (30d)
121

Description

We hit an inconsistent megarepo-store state while unwinding a downstream PR stack from a branch-pinned effect-utils ref back to canonical upstream main.

Observed behavior:

  • downstream repos had temporarily pinned effect-utils to a PR branch ref for validation
  • after the upstream PR merged, we switched the downstream config back to canonical upstream source
  • mr store fix effect-utils reported no issues
  • but mr lock and mr config ... still failed with StoreHygieneError
  • the error still referenced the old effect-utils branch worktree and expected branch schickling/2026-03-21-effect-utils-upstream-nixpkgs-authority

So the commands disagreed:

  • the repair command said the store was clean
  • the normal lock/config commands still considered the store broken

Why this matters:
This is a normal workflow for megarepo PR stacks:

  1. point downstream repos at an upstream PR branch/ref
  2. validate downstream CI
  3. merge upstream
  4. switch downstream back to canonical upstream main
  5. refresh lock files

Right now that last transition can get stuck in a state where mr store fix is a false negative and the only reliable recovery is manual lock editing.

Expected behavior:

  • either mr store fix <member> should fully repair the stale store metadata so mr lock succeeds afterward
  • or it should clearly report that unresolved hygiene problems remain

A minimal repro likely involves:

  • a member pinned to a branch ref
  • downstream config changed back to canonical upstream source
  • store metadata still remembering the old branch/worktree binding

Related but not duplicate:

  • #395
  • #397

Acting on behalf of the user.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the branch-ref to canonical-source transition, then run mr store fix effect-utils, mr lock, and the relevant mr config command to compare their hygiene checks. Inspect the store metadata that still references the old branch worktree; done means the fix either removes that stale binding so lock/config succeed or reports the remaining problem clearly.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.