Required-comment status-change flow isn't transactional (client and server) #37

New Issue

2026-08-31T21:29:44-04:00

jared commented

2026-08-31 21:29:44 -04:00

Severity: Medium

When a status transition requires a comment (e.g. closing a ticket), the comment is persisted before the status update, with no shared transaction or rollback if the second step fails. This shows up in two places:

Client: assets/js/ticket.js (~lines 547-560) — POST /api/add_comment.php runs first, then POST /api/update_ticket.php.
Server: api/ticket_status_api.php (~lines 130-165) — same ordering for the Bearer API's status-change endpoint.

Impact: If the second call fails (network blip, CSRF resync race, workflow re-validation failure) the comment has already been persisted — the ticket is left with a "reason" comment permanently attached but no accompanying status change, and the only user feedback is a generic error toast that doesn't mention the orphaned comment.

Fix: Either combine comment+status-change into a single server-side transactional operation (preferred — add an optional comment param to update_ticket.php that inserts the comment in the same DB transaction as the status update, which ticket_status_api.php already supports per the README), or roll back / delete the comment client-side if the status-update call fails.

**Severity:** Medium When a status transition requires a comment (e.g. closing a ticket), the comment is persisted **before** the status update, with no shared transaction or rollback if the second step fails. This shows up in two places: - Client: `assets/js/ticket.js` (~lines 547-560) — `POST /api/add_comment.php` runs first, then `POST /api/update_ticket.php`. - Server: `api/ticket_status_api.php` (~lines 130-165) — same ordering for the Bearer API's status-change endpoint. **Impact:** If the second call fails (network blip, CSRF resync race, workflow re-validation failure) the comment has already been persisted — the ticket is left with a "reason" comment permanently attached but no accompanying status change, and the only user feedback is a generic error toast that doesn't mention the orphaned comment. **Fix:** Either combine comment+status-change into a single server-side transactional operation (preferred — add an optional `comment` param to `update_ticket.php` that inserts the comment in the same DB transaction as the status update, which `ticket_status_api.php` already supports per the README), or roll back / delete the comment client-side if the status-update call fails.

jared added the priority/medium reliability workflow labels 2026-09-08 10:15:44 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/tinker_tickets#37