Add stop population/update feature

[MMeteorL]

Summary

Adds a Stop button in the Settings dropdown that cancels an in-flight populate or update run. Already-collected rows are kept; the dataset transitions immediately to live and the ready email is sent with the row count collected so far.

How it works

Signal threading

The Vercel AI SDK (and the underlying fetch to OpenRouter) only honours cancellation if an AbortSignal is passed explicitly to the call — controller.abort() does not propagate automatically through async call chains. The signal is threaded via abortSignal to every agent.generate() call:

• Orchestrator (agentStep in populate.ts) — first place a stop fires during population
• run_subagent tool (investigate-tool.ts) — re-throws AbortError so it propagates back up through the tool call to the orchestrator, not swallowed as a structured failure
• Refresh agents (refreshRowsStep in update.ts) — each processRow re-throws AbortError so the worker exits; Promise.allSettled winds all workers down

Stop during populate

agentStep throws AbortError → Mastra marks the step failed → run.start() returns { status: "failed" } → background runner catches it, checks controller.signal.aborted, calls setDatasetPopulateStatus("live") + sendDatasetReadyNotification (skipped if 0 rows).

Stop during update (different path)

processRow re-throws AbortError → workers exit early via Promise.allSettled (no throw) → refreshRowsStep detects signal.aborted after processWithConcurrency returns, calls the new clearAllPendingUpdateStatus Convex mutation to reset any rows that were never reached → step returns normally → Mastra sees success → the existing success path sets "live" and sends the email. This is why the update runner has no abort catch branch — it isn't needed.

Abort registry (abort-registry.ts)

A module-level Map<datasetId, AbortController>. Keyed by datasetId because:

• /stop knows the datasetId from the request body
• Convex's atomic claim guarantees at most one active run per dataset (so datasetId is unique)
• Workflow steps already have authorizedDatasetId/datasetId in their inputData — no extra lookup field needed

This eliminates the need for a second activeDatasets: Map<datasetId, runId> bridging map; the /stop route calls abortDataset(datasetId) directly.

finaliseRunAsLive() helper

Both background runners share the same stop-success sequence: query the dataset, set status "live", count rows, send the ready email. Extracted into a single helper to avoid duplication.

runStats on stop

The existing finally block in agentStep saves runStats regardless of how the step exits — a stopped populate run records status: "error" with error: "Stopped by user" so the run is visible in metrics without polluting the failure count.

Files changed

File	Change
backend/src/abort-registry.ts	New — Map<datasetId, AbortController> with registerDataset, getSignal, abortDataset, deregisterDataset
backend/src/index.ts	Register/deregister runs; finaliseRunAsLive() helper; /stop route; populate abort catch; update runner deregistration
backend/src/mastra/workflows/populate.ts	Pass abortSignal to agent.generate(); label AbortError as "Stopped by user" in runStats
backend/src/mastra/workflows/update.ts	Pass abortSignal to agent.generate(); re-throw AbortError in processRow; bulk-clear pending rows post-abort
backend/src/mastra/tools/investigate-tool.ts	Pass abortSignal to sub-agent; re-throw AbortError to propagate cancellation
frontend/convex/datasetRows.ts	New clearAllPendingUpdateStatus internal mutation — bulk-clears updateStatus: "pending" rows
frontend/lib/backend.ts	New stopPopulation(datasetId, token) → POST /stop
frontend/lib/analytics.ts	Add DATASET_STOP_REQUESTED event
frontend/app/dataset/[id]/page.tsx	handleStop, stopping state; SettingsDropdown swaps Update/Populate for amber Stop button while dataset is busy

Test plan

• Start a populate run, open Settings → Stop button is visible (amber, square-stop icon)
• Click Stop — button shows "Stopping…" briefly, dataset transitions from building to live, existing rows are preserved
• Start an update run, click Stop — pending shimmers clear, dataset transitions to live, existing row data unchanged
• Stop with 0 rows collected — dataset goes live with no email sent
• After a natural completion, Settings shows Update + Clear & Populate (not Stop)
• Run make convex-push to deploy clearAllPendingUpdateStatus before testing the update stop path

🤖 Generated with Claude Code

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds user-initiated stopping for dataset build/update runs: an in-process AbortController registry, wiring of register/abort/deregister into populate/update background runners, propagation of dataset-scoped AbortSignals into agent/subagent calls with AbortError rethrowing, a protected POST /stop endpoint, frontend Stop UI and client, analytics event, and a Convex mutation and schema index to clear pending updateStatus after aborted updates.

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant Frontend
  participant BackendAPI
  participant AbortRegistry
  participant Worker as Populate/Update Worker
  participant Agent
  participant ConvexDB

  User->>Frontend: clicks "Stop"
  Frontend->>BackendAPI: POST /stop (datasetId, Bearer token)
  BackendAPI->>AbortRegistry: abortDataset(datasetId)
  AbortRegistry-->>BackendAPI: abort triggered / no-op
  BackendAPI-->>Frontend: 202 or 200
  par background worker flow
    Worker->>AbortRegistry: registerDataset(datasetId)
    AbortRegistry->>Worker: AbortSignal
    Worker->>Agent: agent.generate(..., abortSignal)
    Agent-->>Worker: throws AbortError
    Worker->>ConvexDB: finaliseRunAsLive / mark failed / clear pending statuses
    Worker->>AbortRegistry: deregisterDataset(datasetId)
  end

Loading

Possibly related PRs

• tinyfish-io/bigset#104: Extends the update background/refresh workflow; overlaps with abort/pending-status handling.
• tinyfish-io/bigset#81: Modifies the same investigate-tool used by this PR (agent/subagent invocation changes).
• tinyfish-io/bigset#85: Prior populate/back-end orchestration edits that interact with the populate-agent error paths modified here.

Suggested reviewers

• simantak-dabhade
• giaphutran12

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Add stop population/update feature' clearly and concisely summarizes the main change: introducing a Stop button to cancel in-flight populate or update runs.
Description check	✅ Passed	The description comprehensively explains the feature, implementation approach (signal threading, different paths for populate vs update), abort registry design, API changes, and includes a detailed test plan aligned with the changeset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/stop-population

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (1)

frontend/lib/backend.ts (1)

115-135: ⚡ Quick win

Route this through the shared backend fetch helper.

This adds another copy of the same fetch/error-parsing/auth-header logic already repeated in this file. Please extract or reuse a single typed request helper here so response-shape and error-handling changes don't drift per endpoint.

As per coding guidelines, "Implement typed fetch wrapper in lib/backend.ts for calling the Fastify backend with Bearer token authentication".

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/lib/backend.ts` around lines 115 - 135, stopPopulation duplicates
fetch/auth/error-parsing logic; replace its direct fetch with the shared typed
fetch wrapper (implement or reuse a helper such as backendFetch/requestWithAuth
that accepts path, method, body, token and returns typed JSON or throws parsed
errors). Modify stopPopulation to call that helper (passing "/stop", method
"POST", { datasetId } and token) and return the typed result, removing the
inline headers, JSON.stringify, and manual res.ok handling so all endpoints
share single error/response handling.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend/src/index.ts`:
- Around line 360-368: When handling controller.signal.aborted and calling
finaliseRunAsLive({ logger, clerk, datasetId, authorizedUserId }), do not
unconditionally return before ensuring the controller registry remains available
if finalisation fails: add a boolean flag (e.g., finaliseSucceeded) set to true
only after finaliseRunAsLive completes successfully, and change the finally
block that currently deregisters the controller so it only removes the
controller when finaliseSucceeded is true (or when the run truly finished),
leaving the /stop registry entry in place if finalisation failed; reference
controller.signal.aborted, finaliseRunAsLive, and the finally block that
deregisters the controller to locate where to add the flag and conditional
deregistration.

In `@backend/src/mastra/tools/investigate-tool.ts`:
- Around line 116-117: The call to agent.generate currently caps subagents at 10
steps; change the maxSteps option to 25 to match the investigate tool contract:
replace agent.generate(prompt, { abortSignal, maxSteps: 10 }) with maxSteps: 25,
and ensure any usage that spawns investigate subagents via
buildInvestigateTool(authorizedDatasetId, authContext, columns) also passes/uses
the 25-step budget and continues to parse the tool's structured output as
expected (refer to getSignal and agent.generate to locate the call to update).

In `@backend/src/mastra/workflows/populate.ts`:
- Around line 237-238: The cancelation is ineffective because the AbortSignal
from getSignal(inputData.authorizedDatasetId) is only passed into agent.generate
at the end; change enumerateStep (and any internal call generateText) to accept
an abortSignal parameter and forward it into agent.generate (or the lower-level
generateText call) so the in-progress text generation can be aborted
immediately; additionally, have enumerateStep check abortSignal.aborted at
sensible points and throw or return early when aborted to ensure the dataset
transitions to live promptly.

In `@frontend/app/dataset/`[id]/page.tsx:
- Around line 173-194: The Stop action un-latches too early because handleStop
clears stopping in the finally block even though the dataset may still be in
"building"/"updating"; change handleStop (and the similar code around lines
212-213) to keep stopping true until the dataset actually leaves the busy
states: setStopping(true) before calling stopPopulation, remove
setStopping(false) from the immediate finally, and instead clear stopping only
after you observe dataset.status !== "building" && dataset.status !== "updating"
(e.g. subscribe to the dataset state update, poll the dataset status once or
listen for the status change event) so the button remains disabled during the
abort/cleanup window and duplicate stop requests/events are prevented.

In `@frontend/convex/datasetRows.ts`:
- Around line 315-330: The mutation clearAllPendingUpdateStatus currently calls
ctx.db.query("datasetRows").withIndex("by_dataset").collect() and patches every
pending row in one run, risking Convex transaction limits; change it to process
rows in bounded batches using pagination (e.g., use the query
withIndex(...).paginate or iterate with a limit and resume token) and patch only
each page's rows, or split the work into repeated smaller internalMutations
until no pending rows remain, while still returning the total cleared; update
references to the query call (datasetRows by_dataset), the collect() usage, and
the ctx.db.patch(row._id, ...) logic to operate per-page with a safe limit and
resume token.

---

Nitpick comments:
In `@frontend/lib/backend.ts`:
- Around line 115-135: stopPopulation duplicates fetch/auth/error-parsing logic;
replace its direct fetch with the shared typed fetch wrapper (implement or reuse
a helper such as backendFetch/requestWithAuth that accepts path, method, body,
token and returns typed JSON or throws parsed errors). Modify stopPopulation to
call that helper (passing "/stop", method "POST", { datasetId } and token) and
return the typed result, removing the inline headers, JSON.stringify, and manual
res.ok handling so all endpoints share single error/response handling.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f093be88-b2b9-4690-a1d3-ac2fa97c7b54

📥 Commits

Reviewing files that changed from the base of the PR and between b097e38 and 7c925d6.

📒 Files selected for processing (9)

• backend/src/abort-registry.ts
• backend/src/index.ts
• backend/src/mastra/tools/investigate-tool.ts
• backend/src/mastra/workflows/populate.ts
• backend/src/mastra/workflows/update.ts
• frontend/app/dataset/[id]/page.tsx
• frontend/convex/datasetRows.ts
• frontend/lib/analytics.ts
• frontend/lib/backend.ts

[MMeteorL]

All pending comments solved, also resolved the potential risk of terminating a run with spurious AbortError. The stop function well in testing on populate run and update run, and this should be good to go.

[giaphutran12]

Requesting changes before merge.

[P1] frontend/app/dataset/[id]/page.tsx:87 introduces setStopping(false) directly inside an effect. In a fresh PR worktree, bun run lint fails with react-hooks/set-state-in-effect on that exact line, so this PR cannot pass the local frontend gate.

Fix: avoid synchronous state updates in the effect. One small option is to schedule the clear (setTimeout(..., 0) with cleanup) or refactor the stop latch so the UI derives pending state from dataset busy status without calling setState directly in the effect body. Re-run bun run lint afterward.

[MMeteorL]

Requesting changes before merge.

[P1] frontend/app/dataset/[id]/page.tsx:87 introduces setStopping(false) directly inside an effect. In a fresh PR worktree, bun run lint fails with react-hooks/set-state-in-effect on that exact line, so this PR cannot pass the local frontend gate.

Fix: avoid synchronous state updates in the effect. One small option is to schedule the clear (setTimeout(..., 0) with cleanup) or refactor the stop latch so the UI derives pending state from dataset busy status without calling setState directly in the effect body. Re-run bun run lint afterward.

Thank you for taking the time to review this! The fix has been applied by removing the effect, and clearing stopping in handlePopulate and handleUpdate.

[giaphutran12]

Holding for launch safety. The old lint issue is fixed, but the stop button state can still stay latched after a successful stop because stopping is never cleared when the dataset leaves building/updating. Please clear the latch from Convex status or derive the button label from the busy state, then rerun checks.

[MMeteorL]

Holding for launch safety. The old lint issue is fixed, but the stop button state can still stay latched after a successful stop because stopping is never cleared when the dataset leaves building/updating. Please clear the latch from Convex status or derive the button label from the busy state, then rerun checks.

The following issues have been fixed, and tests have passed.

Bug 1 — Stop button latch after successful stop
Problem: After clicking Stop and the dataset successfully transitioned out of "building"/"updating", the stopping state was never cleared. The button stayed permanently disabled.

Fix (frontend — frontend/app/dataset/[id]/page.tsx):

Introduced a useEffect that watches isDatasetBusy (derived from Convex's live status). When the dataset leaves the busy state, it schedules setStopping(false) via setTimeout(..., 0) — the setTimeout is required to satisfy the react-hooks/set-state-in-effect lint rule, which prohibits synchronous setState calls in effect bodies.
handleStop no longer clears stopping on success — it stays true until Convex confirms the transition. It only clears immediately on network error, so the user can retry.
stopDisabled = stopping || !isDatasetBusy — both conditions must be false for the button to be active, preventing repeat clicks while a stop request is in flight.

Bug 2 — Stale "building" status after Docker restart
Problem: After a server restart, the in-memory abort registry is wiped, but Convex still shows the dataset as "building"/"updating". Clicking Stop returned a silent no-op, leaving the dataset permanently stuck.

Fix (backend — backend/src/index.ts):

The /stop handler now distinguishes between two cases when abortDataset() returns false:

Before: Treated as "run just finished" — returned 200 with no action.
After: Checks the invariant that the normal finish path always sets a terminal Convex status before deregistering. So if status is still busy but no registry entry exists, the run is definitively orphaned. The handler now force-transitions it to "failed" with the message "Run interrupted: server restarted while building".

Bug 3 — TOCTOU race in abort registry (found during impact audit)
Problem: registerDataset() was called inside the background async functions, after void runXxxWorkflowInBackground() had already returned control to the route handler. A /stop request arriving in that tiny gap would see an empty registry, incorrectly trigger the orphan path, force-transition the dataset to "failed" — and then the real runner would later overwrite it back to "live", corrupting state.

Fix (backend — backend/src/index.ts):

For both /populate and /update: registerDataset() is now called in the route handler, synchronously, before the void call. This guarantees the registry entry is visible the instant the 202 response is sent.
runPopulateWorkflowInBackground was updated to accept the pre-created AbortController as a parameter (instead of creating it internally).
Both background functions had their internal registerDataset() calls removed (replaced with explanatory comments).

[simantak-dabhade]

LGTM Great feature.

Addressed in follow-up commits; proceeding with owner-requested merge.