Bulk operations aren't actually atomic despite the docblock claiming so #33
Open
opened 2026-08-31 21:29:42 -04:00 by jared
·
0 comments
No Branch/Tag Specified
main
development
fix/comment-markdown-persist-18
deploy-2026.09.09-182
deploy-2026.09.09-178
deploy-2026.09.08-172
deploy-2026.09.01-163
deploy-2026.08.08-155
deploy-2026.08.08-151
deploy-2026.08.08-147
deploy-2026.08.08-143
deploy-2026.08.08-139
deploy-2026.07.15-130
deploy-2026.07.15-122
deploy-2026.07.11-107
deploy-2026.06.30-96
deploy-2026.06.30-92
deploy-2026.06.30-88
deploy-2026.06.30-84
deploy-2026.06.30-80
deploy-2026.06.30-76
deploy-2026.06.30-72
deploy-2026.06.30-68
deploy-2026.04.29-49
deploy-2026.04.29-41
deploy-2026.04.18-35
deploy-2026.04.16-31
deploy-2026.04.16-27
deploy-2026.04.16-23
deploy-2026.04.16-11
deploy-2026.04.14-9
Labels
Clear labels
api
bug
concurrency
config
data-integrity
dead-code
documentation
duplicate
enhancement
help wanted
invalid
needs-decision
notifications
performance
priority/docs
priority/high
priority/low
priority/medium
question
rate-limiting
reliability
security
ux
wontfix
workflow
Bearer/internal API surface
Something is not working
Race condition / concurrency bug
Configuration / deployment default
Data correctness / schema / integrity issue
Unused / dead code cleanup
README / docs accuracy
This issue or pull request already exists
New feature
Need some help
Something is wrong
Needs a maintainer decision, not clearly a bug
Matrix / in-app notification bug
Performance or resource-usage concern
Documentation-only gap
High-severity / high-impact issue
Low-severity / cosmetic issue
Medium-severity issue
More information is needed
Rate limiting behavior
Reliability / error-handling gap
Security or access-control impact
User-facing UX/functional bug
This won't be fixed
Ticket status workflow engine
Milestone
No items
No Milestone
Projects
Clear projects
No projects
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: LotusGuild/tinker_tickets#33
Reference in New Issue
Block a user
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.
Severity: Medium
models/BulkOperationsModel.php::processBulkOperation()(~line 99 docblock) states the transaction "ensures atomicity — either all tickets are updated or none are (rolled back on failure)" — but this only happens when$atomic = trueis passed. The only real caller,api/bulk_operation.php(~line 106), never passes it, so it defaults tofalse.Impact: In production, a bulk operation with partial per-ticket failures (e.g. 8 succeed, 2 hit a disallowed workflow transition) commits the 8 successes anyway — actual behavior is best-effort, not atomic, contradicting the documented contract. Admins performing a bulk action may believe it's all-or-nothing when it isn't.
Fix: Either pass
$atomic = truefromapi/bulk_operation.phpif all-or-nothing is the desired UX, or fix the docblock to accurately describe the default best-effort behavior and surface partial-failure results clearly to the admin.