The target toggle read the target and then saved the whole row with its on/off state flipped. If an edit of the same target was saved between that read and that save, the toggle wrote the old name and settings back over it, although the edit had reported success. The toggle now updates only the active column. It can no longer write any other field, so it needs no lock.
The entrypoint toggle is unchanged. An entrypoint has no edit form, so nothing but the toggle changes one after it is created.
The new test submits the edit from a database callback that runs right after the toggle has read the target. The edit therefore always lands between the toggle's read and its write, without depending on timing.
Judgement call: the reverse case is left alone. The target edit still saves the whole row, so a toggle that lands between the edit's read and its save is undone by the edit. The issue asks only that a toggle cannot undo an edit.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/webhooker/issues/431.
The target toggle read the target and then saved the whole row with its on/off state flipped. If an edit of the same target was saved between that read and that save, the toggle wrote the old name and settings back over it, although the edit had reported success. The toggle now updates only the `active` column. It can no longer write any other field, so it needs no lock.
The entrypoint toggle is unchanged. An entrypoint has no edit form, so nothing but the toggle changes one after it is created.
The new test submits the edit from a database callback that runs right after the toggle has read the target. The edit therefore always lands between the toggle's read and its write, without depending on timing.
Judgement call: the reverse case is left alone. The target edit still saves the whole row, so a toggle that lands between the edit's read and its save is undone by the edit. The issue asks only that a toggle cannot undo an edit.
Model: opus-5-5
The target toggle loaded the target and saved the whole row, so an
edit saved between that load and the save was overwritten with the
old name and settings although it had reported success. The toggle
now updates only the active column.
The entrypoint toggle is unchanged: an entrypoint has no edit form,
so the toggle is the only thing that changes one after creation.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #431.
The target toggle read the target and then saved the whole row with its on/off state flipped. If an edit of the same target was saved between that read and that save, the toggle wrote the old name and settings back over it, although the edit had reported success. The toggle now updates only the
activecolumn. It can no longer write any other field, so it needs no lock.The entrypoint toggle is unchanged. An entrypoint has no edit form, so nothing but the toggle changes one after it is created.
The new test submits the edit from a database callback that runs right after the toggle has read the target. The edit therefore always lands between the toggle's read and its write, without depending on timing.
Judgement call: the reverse case is left alone. The target edit still saves the whole row, so a toggle that lands between the edit's read and its save is undone by the edit. The issue asks only that a toggle cannot undo an edit.
Model: opus-5-5
Review passed.
Model: opus-5-5