fix(rivetkit-napi): demote bridge error decode log from warn to debug

[abcxff]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[railway-app]

🚅 Deployed to the rivet-pr-4983 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	May 6, 2026 at 4:27 am
frontend-inspector	❌ Build Failed (View Logs)	Web	May 6, 2026 at 4:19 am
frontend-cloud	❌ Build Failed (View Logs)	Web	May 6, 2026 at 4:19 am
ladle	❌ Build Failed (View Logs)	Web	May 6, 2026 at 4:19 am
mcp-hub	✅ Success (View Logs)	Web	May 6, 2026 at 4:18 am
kitchen-sink	❌ Build Failed (View Logs)	Web	May 6, 2026 at 4:18 am

[abcxff]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(rivetkit-napi): demote bridge error decode log from warn to debug #4983 👈 (View in Graphite)
• fix(rivetkit): use keepAwake for websocket callback tracking to prevent c.vars crash after grace deadline #4978 : 1 other dependent PR (#4984 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

Code Review

Overview

This PR reduces log noise across three sites: demotes a successfully-decoded bridge error log from warn to debug, skips abort-listener registration for fast-path serverless metadata requests, and suppresses expected keepAwake rejection warnings for benign shutdown/poll errors.

The intent is clear and the changes are generally low-risk. One correctness concern worth addressing before merge.

---

Issues

[Bug] needsAbortListener skips the pre-aborted signal check — registry/index.ts lines 123–131

The original code handled two cases: (a) signal already aborted → call abort() immediately, and (b) not yet aborted → register listener. The new code collapses both into the needsAbortListener guard, so when needsAbortListener is false (non-engine metadata request), neither case is handled. If request.signal is already aborted when a metadata poll arrives, the cancelToken is never cancelled and the runtime does unnecessary work.

The fix separates the two concerns:

if (request.signal.aborted) {
  abort();
} else if (needsAbortListener) {
  request.signal.addEventListener("abort", abort, { once: true });
}

This preserves the fast path (no listener churn for metadata polls) while still short-circuiting pre-aborted requests.

---

Feedback

parse_bridge_rivet_error demotion — actor_factory.rs line 982

Correct. Successful decoding of an encoded bridge error is normal operation; surfacing it as warn generated noise on every expected actor error. debug is the right level. The malformed-payload warn on line 978 stays, which is appropriate.

keepAwake benign error classification — registry/native.ts lines 2819–2834

Well-structured. isRivetErrorLike is the correct type guard, the error codes (queue.timed_out, actor.aborted) are genuinely expected during graceful shutdown and polling loops, and the classification pattern matches the existing usages at lines 664 and 1893. Non-benign errors still reach warn.

One minor note: both benign and non-benign paths swallow the rejection (no re-throw from .catch). That matches the pre-existing behavior of the surrounding keepAwake wrapper, so it is consistent — just worth confirming it is intentional.

Comment style

Both added comments follow project conventions (complete sentences, no em dashes, no delta documentation). Good.