You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two people can open the same entry today, and neither is told the other is there. @saariuslystoned raised this in Discord, asking for a lock or a "currently editing" indicator, and noted that agents make the collision more likely.
#2126 is the fix I would want first — it makes the editor echo _rev, so a stale save returns 409 instead of silently replacing a newer draft. But it stops the losing save rather than preventing the collision. Autosave stages a draft revision two seconds after each pause in typing. The admin shows that a draft is pending, but not who staged it or whether they are still there, and it fills the second editor's form from that draft without saying so. The autosave that wins deletes the draft revision it replaced, so the other person's text is not in the revision list either.
This gets worse when the other writer is an agent. The MCP content_update tool accepts _rev but does not require it, so an agent that omits it writes blind, and one that passes it correctly still cannot learn that a person has the entry open. Either way it writes, and with #2126 in place the person's next autosave fails against a change they never saw, leaving their unsaved paragraph nowhere to go.
I would like to add a lock record per entry, taken when someone opens it and refreshed while they edit. I would follow the expiring-lease shape media usage and cron already use rather than invent one. The lock has to survive a save. Released on save, it would be gone two seconds after the next pause. The refresh can ride on the autosave PUT the admin already sends, so it costs no extra request and adds nothing to the logged-out path. Proposed defaults, so this is a yes/no rather than a design thread:
One lock per entry. No field-level locking: the body is usually a single field, so two editors would still land in the same one.
Expiry after a few minutes of inactivity, between the cleanup lease's five and cron's ten, tested on the write rather than swept by the once-a-minute tick.
The second editor sees who holds the lock and can open read-only or take over; a take-over notifies the holder.
A write against someone else's live lock is refused unless the caller opts out, the same 409 WORK_LEASE_ACTIVE already returns, and the MCP tools honour the lock by default rather than overriding it. Agents are the callers a lock matters most for.
Disabled per collection with one setting.
Would you take this, and are those defaults right?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Two people can open the same entry today, and neither is told the other is there. @saariuslystoned raised this in Discord, asking for a lock or a "currently editing" indicator, and noted that agents make the collision more likely.
#2126 is the fix I would want first — it makes the editor echo
_rev, so a stale save returns 409 instead of silently replacing a newer draft. But it stops the losing save rather than preventing the collision. Autosave stages a draft revision two seconds after each pause in typing. The admin shows that a draft is pending, but not who staged it or whether they are still there, and it fills the second editor's form from that draft without saying so. The autosave that wins deletes the draft revision it replaced, so the other person's text is not in the revision list either.This gets worse when the other writer is an agent. The MCP
content_updatetool accepts_revbut does not require it, so an agent that omits it writes blind, and one that passes it correctly still cannot learn that a person has the entry open. Either way it writes, and with #2126 in place the person's next autosave fails against a change they never saw, leaving their unsaved paragraph nowhere to go.I would like to add a lock record per entry, taken when someone opens it and refreshed while they edit. I would follow the expiring-lease shape media usage and cron already use rather than invent one. The lock has to survive a save. Released on save, it would be gone two seconds after the next pause. The refresh can ride on the autosave PUT the admin already sends, so it costs no extra request and adds nothing to the logged-out path. Proposed defaults, so this is a yes/no rather than a design thread:
WORK_LEASE_ACTIVEalready returns, and the MCP tools honour the lock by default rather than overriding it. Agents are the callers a lock matters most for.Would you take this, and are those defaults right?
All reactions