fix(stream): make 1:1 recording possible, rate-limit Stream, lock down debug, give trials chat

[teetangh]

Four P1s from #1134. Three are security or compliance; one is a product capability that was structurally absent.

Stacked on #1137 (which is stacked on #1136). Targets dev so CI and the bots run; the diff shrinks as each parent merges. Merge order: #1136 → #1137 → this.

Recording a 1:1 was impossible, not disabled

isAppointmentOwner and isRecordingEnabledForAppointment each hand-rolled an if/else over webinar and class. For a consultation or subscription, both fell through to false. So:

• the consultant who owned the session failed the ownership check, and POST /api/stream/recordings/start answered 403 to them;
• recording-info reported recordingEnabled: false regardless, above a comment reading "Consultations and subscriptions don't have recordingEnabled on their plans" — accurate, and the reason the whole path was dead.

Fixed properly rather than patched:

• Schema: ConsultationPlan and SubscriptionPlan gain recordingEnabled + recordingStoragePolicy, mirroring WebinarPlan/ClassPlan exactly. Default false — a 1:1 is the most sensitive session type on the platform, so recording stays an explicit per-plan opt-in by the consultant, never implicit.
• One resolver: resolveAppointmentPlan() returns the plan behind an appointment whichever of the four kinds it is, and both predicates read it. They can no longer disagree about which plan they are looking at — which is the shape of the original bug.
• Three routes (recordings/start, recordings/stop, recording-info) had to learn to fetch the 1:1 relations. recording-info already resolved them for the consultant id but not for the flag, which is exactly how the two halves drifted.

Zero rate limiting on anything Stream

Neither /api/stream/ nor /api/meetings/ appeared in RATE_LIMIT_RULES. Two budgets, sized to the two shapes:

Limiter	Budget	Why
streamJoinLimiter	20/min	The meeting join gate. Call ids are deterministic slot-<anchorSlotId>, so this is the enumeration surface — anyone holding one slot id could walk neighbours probing which meetings they can reach. Loose enough that a flaky network retrying a join never trips it.
streamApiLimiter	60/min	/api/stream/* — ordinary authenticated reads and writes, but every unbounded request was also a billable Stream API call.

/api/stream/debug had no session check at all

Its only production gate was a shared secret in the query string — which lands in access logs, browser history and Referer headers — and it dumps an arbitrary user's full Stream channel list. Now requires a session and staff/admin, with the secret demoted to defence in depth. It also fails closed when STREAM_DEBUG_SECRET is unset; the old comparison would have matched undefined against undefined.

Trial buyers had no chat

TRIAL had no branch in channel provisioning, and "trial" was not even in eventTypeSchema, so it could not be requested. A trial buyer got video and no way to message the consultant before or after it — the platform's first impression was the one session type that shipped mute. It now gets the same DM as any other 1:1, so the thread merges if they go on to book.

Verification

• tsc --noEmit clean, prisma validate clean.
• eslint clean on every changed file. (middleware.ts:351 eqeqeq is pre-existing on dev — confirmed by stashing — and == null is deliberate there, so I left it rather than widen a security PR.)
• 2,653 tests pass, 235 suites — including 12 new ones in __tests__/stream/recording-capability.test.ts that assert all four appointment kinds behave identically, that an absent flag defaults closed, that a null consultantProfileId never matches a null caller, and that the two predicates always resolve the same plan.

Needs a db push

Two nullable-with-default columns on each of ConsultationPlan and SubscriptionPlan. Additive only; no renames, no drops, no type changes.

Follow-up, deliberately not here

Recording consent (#1134 P1-7) is still open. The consultee currently sees a passive REC pill only after recording starts — no pre-join disclosure, no opt-out, no consent record. That is a DPDP exposure on a consultation product and it needs a UI flow plus a consent record, which does not belong bolted onto this diff. Enabling 1:1 recording makes it more urgent, not less, which is why the default is false.

Part of #1134

🤖 Generated with Claude Code

https://claude.ai/code/session_019pbBn6yWAr2DXjfACyocUv

Summary by CodeRabbit

• New Features

  • Recording availability now supports consultation and subscription plans, with per-plan opt-in settings.
  • Trial appointments now receive direct-message chat channels.
  • Maintenance mode can restore appointment chat channels after completion.

• Improvements

  • Stream meeting and webhook processing is more reliable during service interruptions.
  • Health checks now include Stream service status.
  • Webhook delivery handling provides stronger validation, duplicate protection, and retry support.

• Security

  • Stream debugging requires authentication and appropriate privileges.
  • Meeting joins and Stream API operations now have dedicated request limits.

[netlify]

✅ Deploy Preview for familiarise ready!

Name	Link
🔨 Latest commit	a3d45d3
🔍 Latest deploy log	https://app.netlify.com/projects/familiarise/deploys/6a7ce1c0aa690200077fa2d6
😎 Deploy Preview	https://deploy-preview-1138--familiarise.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 41 (🔴 down 17 from production) Accessibility: 90 (no change from production) Best Practices: 83 (no change from production) SEO: 82 (🟢 up 8 from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Warning

Review limit reached

@teetangh, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 20 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 49ed1848-ef56-4c72-815a-3408970db7a5

📥 Commits

Reviewing files that changed from the base of the PR and between 8f8fe8a and a3d45d3.

📒 Files selected for processing (2)

• __tests__/stream/webhook-not-rate-limited.test.ts
• middleware.ts

📝 Walkthrough

Walkthrough

This PR adds durable Stream webhook processing, recording eligibility for all appointment plans, circuit-breaker protection, bounded session reconciliation, maintenance channel recovery, Stream health reporting, authenticated debug access, rate limits, and scheduled orphaned-session reconciliation.

Changes

Stream integration hardening

Layer / File(s)	Summary
Durable webhook processing app/api/stream/webhooks/route.ts, lib/stream/webhook-dispatch.ts, lib/webhooks/event-log.ts, app/api/webhooks/utils.ts, scripts/cleanup/sweep-stuck-webhook-events.ts, __tests__/stream/*, __tests__/enterprise/*	Verified webhook receipts are persisted before acknowledgment. Deferred processing validates, dispatches, deduplicates, retries, and records completion. The sweeper now replays Stream events.
Recording eligibility and Stream calls prisma/schema.prisma, lib/stream/recording-utils.ts, lib/stream/recording-service.ts, app/api/stream/meetings/..., app/api/stream/recordings/..., __tests__/stream/recording-capability.test.ts	Consultation and subscription plans add recording controls. Shared plan resolution covers all appointment types. Recording operations use normalized call IDs and the Stream circuit breaker.
Session draining and channel recovery actions/maintenance/drain-sessions.ts, app/api/admin/maintenance/route.ts, lib/stream/appointment-channels.ts, jobs/meetings/reconcile-orphaned-sessions.ts, .github/workflows/reconcile-orphaned-sessions.yml, lib/payments/webhooks/handlers.ts	Maintenance drains bounded live sessions, confirms call termination, updates session state, freezes appointment channels, and unfreezes them after maintenance. Reconciliation runs on a schedule and trial appointments receive direct-message channels.
Health, access, and request controls lib/stream/health.ts, app/api/health/route.ts, app/api/stream/debug/route.ts, lib/rate-limit.ts, middleware.ts	The health endpoint reports Stream status without changing database-based degradation. Debug access requires authentication and privilege. Stream joins and API requests use separate rate limits.

Estimated code review effort: 5 (Critical) | ~120 minutes

Possibly related issues

• Stream SDK subsystem audit v2 — the webhook pipeline has never run, and any signed-in user can join any call #1134 — Directly covers the webhook, reconciliation, maintenance, recording, debug access, rate limiting, and circuit-breaker changes.
• Stream subsystem — the tail #1134's PR train did not close #1144 — Covers Stream session reliability through orphaned-session reconciliation and durable webhook processing.
• feat: Implement Novu webhook receiver for notification delivery tracking #399 — Relates to the shared webhook ingestion and idempotency utilities.

Possibly related PRs

• Practitionist/familiarise_web#1137 — Substantially overlaps the webhook, reconciliation, health, maintenance, and channel changes.
• Practitionist/familiarise_web#1141 — Shares the Stream maintenance, webhook, recording, health, rate-limit, and reconciliation changes.
• Practitionist/familiarise_web#1136 — Shares Stream call CID handling, webhook secret behavior, and recording access hardening.

Poem

A rabbit checks the Stream at night,
Saves each webhook receipt right.
Calls end safely, channels freeze,
Then maintenance brings release.
Plans decide which recordings stay—
Hop, hop, shipped without delay!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 57.14% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the four primary user-facing changes: recording, rate limiting, debug access, and trial chat provisioning.
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.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/stream-correctness

---

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

[coderabbitai]

Actionable comments posted: 25

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

scripts/cleanup/sweep-stuck-webhook-events.ts (1)

152-167: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Skip the Razorpay envelope reconstruction for Stream rows.

Lines 157-167 build envelope for every row, including Stream rows that never use it. Move the construction into the else branch so the Stream path does not pay for it and the code states which provider owns the envelope shape.

🤖 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 `@scripts/cleanup/sweep-stuck-webhook-events.ts` around lines 152 - 167, Move
the Razorpay envelope construction using payloadKeys and envelope into the
non-Stream else branch of the loop over stuck events. Keep the Stream handling
path free of this reconstruction, and preserve the existing
RazorpayWebhookEnvelope shape for Razorpay events.

🤖 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 `@__tests__/enterprise/sweep-stuck-webhook-events.test.ts`:
- Around line 89-93: Add tests for the provider-specific redrive branches in the
sweep-stuck webhook events suite: mock `@/lib/stream/webhook-dispatch` and verify
a stream row calls processStreamEvent with its stored payload, eventType,
eventId, undefined signature, and extracted call_cid; also verify a Razorpay row
still calls processRazorpayWebhookEvent. Keep the existing provider query-filter
assertion unchanged.

In @.claude/skills/stream-sdk/SKILL.md:
- Around line 20-25: Specify a language on the fenced command block containing
the MCP, Supabase, and Netlify commands by changing its opening fence to use
text or shell, while leaving the command contents unchanged.

In @.github/workflows/reconcile-orphaned-sessions.yml:
- Around line 48-55: Update the reconcile workflow’s checkout and Node.js setup
steps to pin actions/checkout@v5 and actions/setup-node@v5 to immutable full
commit SHAs. Add job-level permissions granting only contents: read, and set
persist-credentials: false in the checkout step.
- Around line 60-64: Pin the workflow tools to project dependencies by adding
tsx@4.23.1 to package.json and package-lock.json, then update both the Prisma
client generation step and the orphaned session reconciliation step to use npx
--no-install. Preserve the existing commands and the reconciliation entry point.

In `@actions/maintenance/drain-sessions.ts`:
- Around line 181-195: Wrap the maintenance warning request in the same bounded
best-effort mechanism used for Stream operations, rather than relying on the
trailing catch after sendCallEvent settles. Update the sendCallEvent flow in the
session drain logic so a degraded API cannot delay call.end(), while preserving
the notification counter increment on successful delivery and the existing
withStreamCircuitBreaker call for ending the session.
- Around line 196-220: Update the session-draining flow around call.end() and
the subsequent prisma.$transaction so database completion is persisted only
after a successful end or a confirmed already-ended response. Detect
StreamUnavailableError and other unconfirmed failures, record the error without
marking the meeting session ended or the slot UNVERIFIED, and retry those
failures according to the existing retry mechanism.
- Around line 56-63: Update the activeSessions query in the drain flow to
exclude sessions whose appointment slot has not started by adding a startsAt <=
now condition to slotOfAppointment. Preserve the existing endsAt >= liveSince
and endedAt: null filters, and use the current time value consistently for the
startsAt comparison.

In `@app/api/meetings/`[meetingId]/join/route.ts:
- Around line 100-110: Update the join route’s error handling around
withStreamCircuitBreaker to import and detect StreamUnavailableError from
`@/lib/stream-client` before the generic catch. Log a warning and return the
existing retryable HTTP 503 response used for missing Stream configuration,
while preserving generic error handling for other failures.
- Around line 112-122: Update the admission flow surrounding the join route’s
membership check and updateCallMembers operation to enforce an attendee ceiling
or rate-limit/burst-handling strategy before admitting users. Preserve
membership-gated access, reject admissions beyond the configured plan or safe
Stream request capacity, and avoid issuing one unbounded updateCallMembers
request per attendee.

In `@app/api/stream/webhooks/route.ts`:
- Around line 140-154: Update the fallback event-key construction in the webhook
route to preserve every identity field’s position. Remove the `.filter(Boolean)`
call before `.join("_")`, keeping the existing empty-string placeholders and
direct join behavior so distinct field combinations cannot collapse to the same
key.
- Around line 158-165: Record the webhook durably before acknowledging it: in
app/api/stream/webhooks/route.ts lines 158-165, call logWebhookEvent("stream",
eventId, eventType, event, signature) before the after() handoff and 200
response. In lib/stream/webhook-dispatch.ts lines 200-208, move the
isDbHealthy() gate after recording the row or preserve a re-drivable row on
early return, and align both call sites’ claim semantics so processStreamEvent
does not treat the pre-ACK row as a duplicate.
- Around line 118-119: Update the webhook route’s JSON parsing and catch
handling around JSON.parse and the existing z.ZodError branch so malformed JSON
SyntaxError failures return the documented 400 response instead of falling
through to 500. Preserve the existing 400 behavior for validation errors and
ensure malformed deliveries stop retries.
- Around line 65-77: The webhook handling flow around getWebhookSecret must
decompress gzip-compressed Stream deliveries before signature verification and
JSON parsing, because Stream signs the uncompressed body. Update the route to
use the existing verifyAndParseWebhook helper if available, or otherwise detect
and decompress the request body before hashing and parsing while preserving
STREAM_API_SECRET and the X-Signature/X-Webhook-Id headers.

In `@app/meetings/`[id]/hooks/useGetCallById.ts:
- Around line 66-77: Update the non-OK response handling in the join-request
flow around setAccess to treat only HTTP 401 and 403 as access denials; route
HTTP 429 and all 5xx responses into the existing error state instead. Ensure the
error path does not leave access populated, since the page checks access before
error, and preserve the current response-message extraction for both outcomes.
- Around line 50-62: Update the request lifecycle in the hook’s run effect
around the join fetch to create an AbortController, pass its signal to fetch,
and call abort from cleanup when the component unmounts or callId changes.
Propagate the same cancellation through the subsequent callInstance.get()
operation if supported, while retaining the cancelled check first in the catch
block so AbortError is ignored before logging.

In `@lib/meetings/access.ts`:
- Around line 150-155: Update MeetingAccess and every return path in
resolveMeetingAccess to include a reason discriminant, using "not_found" for the
missing-meeting path. In app/api/meetings/[meetingId]/join/route.ts lines 81-94
and app/api/meetings/[meetingId]/validate-access/route.ts lines 44-58, select
the HTTP status using access.reason === "not_found" instead of comparing
access.message; the message should remain user-facing text only.

In `@lib/payments/webhooks/handlers.ts`:
- Around line 925-939: The direct-message channel must be provisioned durably
before payment or approval flows report success. In
lib/payments/webhooks/handlers.ts:925-939,
app/api/bookings/consultations/[consultationId]/route.ts:801-808, and
app/api/bookings/subscriptions/[subscriptionId]/route.ts:827-834, enqueue an
idempotent channel-provisioning command within each transaction instead of
provisioning only after success; ensure the command retries
createDirectMessageChannel until it succeeds, including redeliveries and
duplicate approvals.

In `@lib/stream/health.ts`:
- Around line 35-49: Update the health probe around
getStreamChatClient().getAppSettings() to use a short, SDK-supported request
timeout or AbortSignal that actually cancels the request. Ensure probe deadline
expiry is propagated through withStreamCircuitBreaker so it trips the breaker,
then preserve the catch response with reachable: false and breakerOpen
reflecting the resulting StreamUnavailableError.

In `@lib/stream/webhook-dispatch.ts`:
- Around line 43-59: Replace the separate HANDLED_EVENT_TYPES list and dispatch
switch with one event-type table keyed by event name, containing each event’s
schema and handler. Derive the route gate’s accepted types from that table and
use the same table for dispatch, including existing validation and default
handling behavior. Update the affected webhook routing logic around the
dispatcher so adding an event cannot leave the gate and dispatch out of sync.
- Around line 312-329: Update the inner error handling around the schema parse
cases and markWebhookEventProcessed so z.ZodError validation failures produce a
terminal error string prefixed with "gave up:". Preserve the existing retryable
error text for non-validation handler failures, allowing the sweeper to exclude
validation failures while continuing to retry transient errors.

In `@lib/webhooks/event-log.ts`:
- Around line 147-165: Remove the contradictory “processed=true only on success”
sentence from the docstring above markWebhookEventProcessed, while preserving
the explanation that failures record an error and leave processed=true for retry
detection.
- Around line 93-118: Update the stale-recovery and failed-retry branches in the
event-processing flow to atomically claim the row with conditional updateMany
calls. In the stale path, guard the claim with the existing event identity and
in-progress state; in the failed-retry path, also require error: { not: null }.
Treat a zero updated count as another worker owning the event and return the
existing non-new result, ensuring only the successful claimant returns isNew:
true.

In `@middleware.ts`:
- Around line 264-271: Update the “stream: api” limiter match predicate to
exclude the exact /api/stream/webhooks route while continuing to rate-limit
other /api/stream/ user-facing routes. Preserve the existing limiter
configuration and localhost behavior, and verify whether any additional
machine-to-machine endpoints under the prefix require the same exclusion before
finalizing the predicate.
- Around line 253-263: The meeting join flow currently limits by client IP
instead of the authenticated user. Update the join handler after
auth.api.getSession() to apply an Edge-compatible rate limiter keyed by
session.user.id, while preserving the existing unauthenticated handling and
streamJoinLimiter rule; do not rely solely on middleware or comment changes.

In `@scripts/cleanup/sweep-stuck-webhook-events.ts`:
- Around line 170-188: Make the terminal give-up handling provider-aware: when
the sweep stamps an event past giveUpAfterHours, use a Stream-specific reason
for ev.provider === "stream" instead of "gave up: payment never arrived", while
preserving the existing payment reason for other providers. Update the
deferred-event handling logic near the sweep’s terminal classification, not the
processStreamEvent dispatch branch.

---

Outside diff comments:
In `@scripts/cleanup/sweep-stuck-webhook-events.ts`:
- Around line 152-167: Move the Razorpay envelope construction using payloadKeys
and envelope into the non-Stream else branch of the loop over stuck events. Keep
the Stream handling path free of this reconstruction, and preserve the existing
RazorpayWebhookEnvelope shape for Razorpay events.

🪄 Autofix

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: ASSERTIVE

Plan: Pro Plus

Run ID: 92737539-6555-4f01-86df-76e82592def1

📥 Commits

Reviewing files that changed from the base of the PR and between 6b40937 and 6bd3ef6.

📒 Files selected for processing (39)

• .claude/skills/stream-sdk/SKILL.md
• .github/workflows/reconcile-orphaned-sessions.yml
• __tests__/enterprise/sweep-stuck-webhook-events.test.ts
• __tests__/security/dm-channel-org-precedence.test.ts
• __tests__/stream/recording-capability.test.ts
• __tests__/stream/stream-client.test.ts
• actions/maintenance/drain-sessions.ts
• app/api/bookings/consultations/[consultationId]/route.ts
• app/api/bookings/subscriptions/[subscriptionId]/route.ts
• app/api/health/route.ts
• app/api/meetings/[meetingId]/join/route.ts
• app/api/meetings/[meetingId]/validate-access/route.ts
• app/api/stream/debug/route.ts
• app/api/stream/meetings/[streamCallId]/recording-info/route.ts
• app/api/stream/recordings/start/route.ts
• app/api/stream/recordings/stop/route.ts
• app/api/stream/webhooks/route.ts
• app/api/webhooks/utils.ts
• app/meetings/[id]/hooks/useGetCallById.ts
• app/meetings/[id]/page.tsx
• jobs/meetings/reconcile-orphaned-sessions.ts
• lib/meetings/access.ts
• lib/moderation/side-effects.ts
• lib/payments/webhooks/handlers.ts
• lib/rate-limit.ts
• lib/stream-channel-ids.ts
• lib/stream-client.ts
• lib/stream-utils.ts
• lib/stream/appointment-channels.ts
• lib/stream/call-cid.ts
• lib/stream/health.ts
• lib/stream/recording-service.ts
• lib/stream/recording-utils.ts
• lib/stream/webhook-dispatch.ts
• lib/webhooks/event-log.ts
• middleware.ts
• prisma/schema.prisma
• scripts/cleanup/sweep-stuck-webhook-events.ts
• scripts/stream/ensure-call-type-grants.ts

[coderabbitai]

Actionable comments posted: 6

🤖 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 `@__tests__/stream/webhook-durability.test.ts`:
- Around line 59-65: Add a durability test covering the pre-ack claim collision
between recordStreamEventReceipt and processStreamEvent: configure
mockLogWebhookEvent to return isNew true for the receipt and false for the
subsequent webhook claim, then assert the registered handler still runs. Keep
the existing default stubs for unrelated tests and verify the ordering contract
through the relevant process flow.

In `@actions/maintenance/drain-sessions.ts`:
- Line 247: Track a durable frozen-channel set for each maintenance window and
always reverse exactly that set: in
actions/maintenance/drain-sessions.ts:247-247, freeze only channels whose
session completion is persisted or persist every frozen channel; in
actions/maintenance/drain-sessions.ts:357-364, load that window’s durable set
instead of discovering channels via the six-hour window or MAX_DRAIN_BATCH; in
app/api/admin/maintenance/route.ts:357-373, execute channel recovery
independently of runPostRecovery() failures so an OFF transition always
unfreezes channels.
- Around line 227-236: Update drainActiveSessions() to catch failures from the
per-session prisma.$transaction after call.end() succeeds, append the caught
error to result.errors, and continue processing subsequent active sessions
instead of rejecting the batch. Preserve reconciliation behavior for the
already-ended call row.

In `@lib/stream/recording-service.ts`:
- Around line 132-138: Update getCallRecordingsFromStream to rethrow
StreamUnavailableError instead of converting open-breaker failures to an empty
array, and update both per-session sync-loop catch blocks to propagate that
error rather than returning { synced: 0 }; preserve existing handling for other
errors.

In `@lib/stream/webhook-dispatch.ts`:
- Around line 242-260: The duplicate WebhookEvent claim prevents first-time
Stream events from reaching their handler. In
lib/stream/webhook-dispatch.ts:242-260, update processStreamEvent to accept or
recognize the receipt claim already made by the caller and continue dispatching
instead of returning on that matching in-progress row; in
app/api/stream/webhooks/route.ts:177-194, align recordStreamEventReceipt with
the dispatch claim so the pre-ack receipt is not treated as another worker’s
claim; in __tests__/stream/webhook-durability.test.ts:59-65, replace the
unconditional logWebhookEvent stub with coverage for an already-recorded second
claim and assert the handler still runs.

In `@lib/webhooks/event-log.ts`:
- Around line 48-147: Reduce cognitive complexity in logWebhookEvent by
extracting the failed-retry and stale in-progress claim logic into a shared
helper such as claimExistingEvent(eventId, where, payload). Have the helper
perform the conditional updateMany, return whether the row was claimed along
with the event record identifier as needed, and preserve the existing state
resets, payload/receivedAt updates, and count-based race handling. Replace both
branches in logWebhookEvent with their appropriate where clauses and logging
while keeping current retry and skip behavior unchanged.

🪄 Autofix

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: ASSERTIVE

Plan: Pro Plus

Run ID: a7c53d72-11b3-4e20-b16d-30f35a631215

📥 Commits

Reviewing files that changed from the base of the PR and between 6bd3ef6 and 8f8fe8a.

📒 Files selected for processing (10)

• .github/workflows/reconcile-orphaned-sessions.yml
• __tests__/stream/webhook-durability.test.ts
• __tests__/stream/webhook-event-log-claim.test.ts
• actions/maintenance/drain-sessions.ts
• app/api/admin/maintenance/route.ts
• app/api/stream/webhooks/route.ts
• lib/payments/webhooks/handlers.ts
• lib/stream/recording-service.ts
• lib/stream/webhook-dispatch.ts
• lib/webhooks/event-log.ts

[sonarqubecloud]

❌ The last analysis has failed.

See analysis details on SonarQube Cloud