mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-21 01:53:33 +00:00
xarmian
fab38336f4
CreateActivity returned the id of the row it had just FAILED to insert. CreateActivityDebounced returned the id of the row it had CHOSEN but not written. The item-update handler discarded the error and linked a user's comment to whatever came back, so the comment appeared under an activity entry describing a different change — attributed, by TASK-2760's agent-name rule, to whoever wrote that entry. The request answered 200. The contract is now: a non-nil error is always paired with an empty id. Three error returns changed and the function's doc states the rule, so no future caller can misuse a value that looks usable. The item-update handler CHECKS the error and logs it. It deliberately does NOT re-zero the id: with the contract fixed that would be a second mechanism for a window the first already covers, it would hide which one is load-bearing, and it would keep passing if the contract regressed. The log is the part nothing else provides. The population the filing left open: logActivityWithMetaReturningID has exactly three callers, and the two comment handlers ALREADY guarded correctly. This brings the third in line with its siblings rather than inventing a pattern — which is why the caller-side half is one line. TESTS, and two instrument failures found on the way: - The first fixture reached a different branch. Closing the database made the CANDIDATE READ fail, so the call fell back to CreateActivity and the merge's error return never executed — the assertion passed for a reason unrelated to the line under test, and the mutation restoring `return existingID, err` survived. BUG-2770's afterDebounceRead seam fires between the read and the write, which is the window that matters. - "No instrument can reach it", written on the classifier's error return, was a fact about the seams I had written rather than about the code. Review pointed at the seam I had not written; afterDebounceRefusal fires between the zero-row refusal and the probe, and that mutation now dies. 5 mutations aimed, 4 die. The survivor is the handler's log line, kept and documented in place: asserting it needs an activity write that fails while the item update succeeds, and a seam existing only so a test can read a log line is not worth a field on Server. Also corrected: a comment in the comment handler that said CreateActivity returns an id on insert failure. True when written, falsified by this change, and missed by my own sweep because I grepped the mechanism's name instead of the claim.