fix: prevent user-input activities from leaking into pending approvals projection

[marcusgrando]

Summary

Threads that used user-input prompts (structured questions to the user) permanently display "Pending Approval" in the sidebar even after all inputs have been answered and the turn has completed.

Root cause

applyPendingApprovalsProjection in ProjectionPipeline.ts does not filter by activity.kind before creating pending-approval rows. The logic:

1. Extracts requestId from any activity payload via extractActivityRequestId
2. Checks if the activity is approval.resolved → skip
3. Checks if the activity is provider.approval.respond.failed → skip
4. Default: creates a row with status = "pending" for any remaining activity with a requestId

Activities like user-input.requested and user-input.resolved carry a requestId in their payload, so they fall through to the default branch and create orphan pending-approval rows. When user-input.resolved arrives, it also falls through and overwrites the row with status = "pending" again (since it's not approval.resolved).

These orphan rows are never cleaned up because only approval.resolved can resolve them.

Contrast with backfill migration

The backfill migration 024_BackfillProjectionThreadShellSummary.ts correctly filters by kind = 'approval.requested' when seeding pending-approval rows (line 36). The live projection was missing this same guard.

Operation	Migration 024 (backfill)	Live projection (before fix)
Create pending row	WHERE kind = 'approval.requested' ✅	Any activity with requestId ❌
Resolve row	WHERE kind = 'approval.resolved' ✅	kind === "approval.resolved" ✅
Stale cleanup	WHERE kind = 'provider.approval.respond.failed' ✅	Matching stale detail strings ✅

Fix

Add a kind !== "approval.requested" guard before the pending-row creation path, so only actual approval requests create entries in projection_pending_approvals. User-input activities already have their own accounting via derivePendingUserInputCountFromActivities.

Verified with real data

A thread with 11 answered user-input prompts had 11 orphan pending rows in projection_pending_approvals, all with status = "pending" and resolved_at = null, even though every single one had a matching user-input.resolved event in the event store. The thread's session was status = "ready" with active_turn_id = null.

Test plan

• All 18 ProjectionPipeline.test.ts tests pass
• All 82 related orchestration tests pass (ProjectionPipeline, ProviderRuntimeIngestion, ProviderCommandReactor, projector)
• Verify sidebar no longer shows "Pending Approval" for threads with only answered user-input prompts

---

Note

Low Risk
Small, localized change to projection logic that narrows when pending-approval rows are created; risk is limited to approval sidebar/count behavior.

Overview
Fixes an issue where user-input.* activities that include a requestId could incorrectly create/overwrite projection_pending_approvals rows, leaving threads stuck showing Pending Approval.

applyPendingApprovalsProjection now only creates status="pending" rows for activity.kind === "approval.requested", while keeping existing resolve/stale-failure handling intact.

^{Reviewed by Cursor Bugbot for commit 51ea2b1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix pending approvals projection to only process approval.requested activities

Previously, any activity event carrying a requestId could upsert a row into the pending-approval repository, causing user-input activities to leak into the pending approvals projection. A guard is added in ProjectionPipeline.ts that returns early unless event.payload.activity.kind === 'approval.requested'.

^{Macroscope summarized 51ea2b1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: f6d87d32-6693-4f14-8f64-612046babf6e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[macroscopeapp]

Approvability

Verdict: Approved

This is a straightforward bug fix that adds a guard clause to filter out user-input activities from polluting the pending-approvals projection. The change is small (8 lines), well-documented with comments explaining the intent, and has clear, limited scope - it simply adds an early return for activity kinds that shouldn't create pending-approval rows.

^{You can customize Macroscope's approvability policy. Learn more.}