fix(tasks): make bulk status changes atomic

[tinsever]

what changed?

a bulk status request could update one project before discovering that another project rejected the status. validate all destinations first, commit the writes together, and publish events after commit.

finding 09 from the codebase review.

how did you check it?

postgres multi-project status regression proving failed requests leave all tasks unchanged.

checked the combined fix tree with the full workspace test run, uncached workspace typechecks, lint, i18n and openapi checks. postgres integration tests used disposable local test databases; provider and s3 calls were mocked.

Native GitHub stack #1886 (bottom to top): #1873 (this PR) → #1876 → #1877 → #1878 → #1879. Stack base: fix/review-06-integration-scope, the shared #1867 foundation. Merge #1867 first, then move this stack's base to main before merging board changes. If GitHub has not moved it automatically, unstack the still-open board PRs, retarget #1873 to main, and recreate this native stack in the same order.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-30T11:12:28.920376Z	3d62ef3	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

⚠️ Mixed activity

Activity patterns show a mix of organic and automated signals.

View full analysis →

_{This is an automated analysis by AgentScan}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Make bulk task status changes atomic across projects

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

AI Description

• Validate every project’s destination before changing any task status.
• Commit status changes together, then publish events using the committed task values.
• Add a PostgreSQL regression test confirming invalid destinations leave all tasks unchanged and
 emit no events.

Diagram

graph TD
  R["Bulk status request"] --> V["Project validation"] --> D["Column destinations"] --> T["Status transaction"] --> DB[("Task database")] --> E["Post-commit events"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Validate inside the transaction

• ➕ Could reduce the gap between destination validation and status updates if columns change concurrently.
• ➖ Would keep a transaction open during per-project validation and require validation queries to use its connection.

Recommendation: The proposed prevalidation followed by one transaction directly fixes partial updates without holding a transaction open for every validation query. Consider transaction-scoped validation separately only if concurrent column changes must be guarded against.

Files changed (2) +93 / -33

Bug fix (1) +51 / -33

bulk-update-tasks.tsCommit multi-project status changes together +51/-33

Commit multi-project status changes together

• Validates and resolves destination columns for every project before writing. Updates tasks in one transaction, rejects project mismatches, and publishes refresh and status-change events after commit using returned task values.

apps/api/src/task/controllers/bulk-update-tasks.ts

Tests (1) +42 / -0

bulk-task-atomic-status.test.tsCover invalid destination across two projects +42/-0

Cover invalid destination across two projects

• Adds a PostgreSQL integration regression test in which the second project lacks the requested status. It verifies the request fails without changing either task or publishing events.

tests/api-integration/bulk-task-atomic-status.test.ts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 69e67e339d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Task details stay stale after no-op updates ✓ Resolved

Description

bulkUpdateTasks guards task.status_changed using only before.status !== updatedTask.status,
even though the update can also change columnId and updatedAt. When a task already has the
requested status but its column assignment is stale, task-relation.refresh refreshes relations and
the board without invalidating the open task’s detail query.

Code

apps/api/src/task/controllers/bulk-update-tasks.ts[R155-157]

+        const before = tasks.find((task) => task.id === updatedTask.id)!;
+        if (before.status !== updatedTask.status)
       await publishEvent("task.status_changed", {
-            taskId: task.id,
-            projectId,

Evidence

The bulk update writes status and columnId, but its status-event guard compares only the previous
and updated status, so a same-status write can omit the per-task event. The WebSocket handler sends
a per-task update for a status event, whereas the project-wide relation refresh invalidates
relations and the board but not the individual task-detail query.

AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers: AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers: AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers: AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers: AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers: AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers: AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers: AGENTS.md: Publish and Deliver Mutation Events Across Realtime Consumers
apps/api/src/task/controllers/bulk-update-tasks.ts[125-140]
apps/api/src/task/controllers/bulk-update-tasks.ts[154-170]
apps/web/src/hooks/use-project-websocket.ts[81-127]
apps/api/src/task/controllers/bulk-update-tasks.ts[125-156]
apps/api/src/ws/index.ts[418-435]
apps/api/src/ws/index.ts[507-535]
apps/web/src/hooks/use-project-websocket.ts[83-121]
apps/web/src/hooks/queries/task/use-get-task.ts[4-12]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A same-status bulk request can change a task’s persisted fields without sending the per-task update needed to refresh its details.
## Fix Focus Areas
- apps/api/src/task/controllers/bulk-update-tasks.ts[125-170]
- apps/web/src/hooks/use-project-websocket.ts[83-121]
## Recommended Fix
Ensure every row whose persisted data changes emits a per-task update, including same-status column changes, without creating an inaccurate status-change activity event. Alternatively, avoid writing rows whose status and column assignment are already correct. Preserve post-commit event ordering.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Bulk-update conflict errors lack documentation ✓ Resolved

Description

bulkUpdateTasks introduces an HTTP 409 response when a task no longer belongs to its initially
selected project, but the bulk route declares no 409 response. A concurrent project move can
therefore produce an error absent from the route contract and committed OpenAPI documentation.

Code

apps/api/src/task/controllers/bulk-update-tasks.ts[R141-144]

+          if (changed.length !== projectTaskIds.length)
+            throw new HTTPException(409, {
+              message: "Tasks changed projects; retry the operation",
+            });

Evidence

The changed controller throws HTTP 409, whereas the route response map lists only 200, 400, 403, and
404.

AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts: AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts: AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts: AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts: AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts: AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts: AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts: AGENTS.md: Keep OpenAPI Documentation Aligned With API Contracts
apps/api/src/task/controllers/bulk-update-tasks.ts[141-144]
apps/api/src/task/index.ts[136-151]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The bulk route can now return HTTP 409, but its published response contract does not include that outcome.
## Fix Focus Areas
- apps/api/src/task/index.ts[136-151]
- apps/docs/openapi.json[1-1]
## Recommended Fix
Add a 409 error response to the bulk route's OpenAPI definition and regenerate the committed OpenAPI artifact.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Large bulk requests slow down quadratically ✓ Resolved

Description

bulkUpdateTasks calls tasks.find() for each updated row to recover its previous status,
repeatedly scanning the original task snapshot. Because the request schema imposes no maximum task
count, large bulk requests make post-commit event preparation quadratic, even when all tasks belong
to one project.

Code

apps/api/src/task/controllers/bulk-update-tasks.ts[R154-155]

+      for (const updatedTask of updatedTasks) {
+        const before = tasks.find((task) => task.id === updatedTask.id)!;

Evidence

The post-commit loop performs a linear search through tasks for every row in updatedTasks, while
the request schema permits an unbounded number of task IDs. Together, these show that event
preparation adds quadratic in-memory work as bulk requests grow.

AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient
apps/api/src/task/controllers/bulk-update-tasks.ts[149-166]
apps/api/src/task/controllers/bulk-update-tasks.ts[149-161]
apps/api/src/task/schema.ts[51-63]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Per-row `tasks.find()` calls make post-commit event preparation quadratic for large bulk requests.
## Fix Focus Areas
- apps/api/src/task/controllers/bulk-update-tasks.ts[149-166]
- apps/api/src/task/schema.ts[51-63]
## Recommended Fix
Build a map of the original tasks keyed by task ID once before the event loop, then use constant-time lookups to recover each updated task's previous status while publishing events.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View high (2)

4. Bulk updates fetch unused task columns ✓ Resolved

Description

bulkUpdateTasks returns nearly every task column from each database update although its subsequent
event logic reads only the identifier, project, status, title, and assignee. For task-heavy
requests, the extra columns are transferred and retained for every updated row without contributing
to the response or events.

Code

apps/api/src/task/controllers/bulk-update-tasks.ts[R137-140]

+            .returning({
+              ...getTableColumns(taskTable),
+              description: sql<null>`null`,
+            });

Evidence

The new getTableColumns(taskTable) selection returns columns beyond those read from updatedTask
in the event loop; the task schema includes positions, dates, priority, and other unused fields.

AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient: AGENTS.md: Keep Task-Heavy Boards and Realtime Updates Efficient
apps/api/src/task/controllers/bulk-update-tasks.ts[137-140]
apps/api/src/task/controllers/bulk-update-tasks.ts[149-166]
apps/api/src/database/schema.ts[425-464]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The transaction returns task columns that the bulk-status response and subsequent events do not use.
## Fix Focus Areas
- apps/api/src/task/controllers/bulk-update-tasks.ts[119-140]
- apps/api/src/task/controllers/bulk-update-tasks.ts[149-166]
## Recommended Fix
Replace the full-column returning selection with the specific fields needed for the count and post-commit events.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. Successful cross-project updates lack a test ✓ Resolved

Description

bulk-task-atomic-status.test.ts exercises only a destination-validation failure and asserts that
no event is published. The existing successful bulk-status test uses one project, leaving the new
multi-project commit and post-commit event sequence unverified.

Code

tests/api-integration/bulk-task-atomic-status.test.ts[R30-37]

+  await expect(
+    bulkUpdateTasks({
+      taskIds: tasks.map((task) => task.id),
+      operation: "updateStatus",
+      value: "in-progress",
+      userId: user.id,
+    }),
+  ).rejects.toThrow("Invalid status");

Evidence

The added test expects rejection and no publication; the existing event-snapshot success case
creates tasks only in a single project.

AGENTS.md: Test Affected Behavior at the Appropriate Level: AGENTS.md: Test Affected Behavior at the Appropriate Level: AGENTS.md: Test Affected Behavior at the Appropriate Level: AGENTS.md: Test Affected Behavior at the Appropriate Level: AGENTS.md: Test Affected Behavior at the Appropriate Level: AGENTS.md: Test Affected Behavior at the Appropriate Level: AGENTS.md: Test Affected Behavior at the Appropriate Level: AGENTS.md: Test Affected Behavior at the Appropriate Level
tests/api-integration/bulk-task-atomic-status.test.ts[16-42]
tests/api-integration/bulk-task-events.test.ts[18-48]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new regression test covers rejection before a write but not the successful multi-project transaction or its post-commit events.
## Fix Focus Areas
- tests/api-integration/bulk-task-atomic-status.test.ts[16-42]
## Recommended Fix
Add a PostgreSQL integration case that updates tasks in two projects, checks both persisted destinations, and verifies that the corresponding events are published after commit.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[tinsever]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: 5a05383473

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[tinsever]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: 3d62ef3b2b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".