mathias/hyperguild
1
0
Fork 0
Code Issues 30 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Only notes.Edit takes the per-note edit lock; other writers of the same notes do not #197

New Issue
Open
opened 2026-10-05 21:43:27 +00:00 by mathias · 0 comments
mathias commented 2026-10-05 21:43:27 +00:00
Owner
Copy Link
Copy Source

Source: PR #194 review round 2 (non-blocking 3), 2026-10-05. This predates #194.

The comment on the edit lock says other writers (brain-fix, brain-enrich, the pipeline, brain_update, brain_tunnel, promote) write the same tree. But notes.Edit is the only flock user in the repo. So a brain_edit and, for example, a brain_update or a pipeline revision of the same note do not exclude each other, across pods or within one. Writes are atomic per file, so the result is a lost update, not a torn file.

Options:

  • Route every note writer through the same lock (notes.flockFile moved into brainfs or a shared package).
  • Or document that only brain_edit is serialised and that last-writer-wins applies to everything else.

Related: #196 (the snapshot outside the lock).

Rollout note from the same review: during the RollingUpdate that deploys #194, an old pod (which unlinks after unlocking) and a new pod do not exclude each other. From the following rollout on, the lock holds.

Created via git-mcp on behalf of @mathias

**Source:** PR #194 review round 2 (non-blocking 3), 2026-10-05. This predates #194. The comment on the edit lock says other writers (brain-fix, brain-enrich, the pipeline, brain_update, brain_tunnel, promote) write the same tree. But `notes.Edit` is the only flock user in the repo. So a `brain_edit` and, for example, a `brain_update` or a pipeline revision of the same note do not exclude each other, across pods or within one. Writes are atomic per file, so the result is a lost update, not a torn file. **Options:** - Route every note writer through the same lock (`notes.flockFile` moved into brainfs or a shared package). - Or document that only `brain_edit` is serialised and that last-writer-wins applies to everything else. **Related:** #196 (the snapshot outside the lock). **Rollout note from the same review:** during the RollingUpdate that deploys #194, an old pod (which unlinks after unlocking) and a new pod do not exclude each other. From the following rollout on, the lock holds. --- _Created via git-mcp on behalf of @mathias_
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agent/ready
Meets the agent-ready contract; authorizes unattended execution
 blocked/client
Waiting on the client
 blocked/supplier
Waiting on a supplier
 blocked/upstream
Waiting on an upstream project or vendor
 risk/high
Irreversible, security-relevant, or control plane
 risk/low
Reversible, local, test-covered
 risk/medium
Touches shared state, deploys or data
 size/l
Too big - split it
 size/m
Under two days
 size/s
Under half a day
 size/xs
Under an hour
 status:dispatch
status:dispatched
status:review
status:reviewing
type/chore
Maintenance, no behaviour change
 type/decision
Human decision required; never agent/ready
 type/docs
Documentation only
 type/feat
New capability
 type/fix
Corrects broken behaviour
 type/ops
Infrastructure, deploy, runtime
 type/research
Investigate; output is a finding, not code
 type/test
Test coverage only
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
renovate-bot mathias
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/hyperguild#197