fix: enforce Croco lifecycle policies for tRPC procedures - #1734
Conversation
|
Warning Review limit reached
Next review available in: 48 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 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 configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (14)
📝 WalkthroughWalkthroughtRPC 라우터가 Croco 실행 컨텍스트를 생성하고 가드, 인터셉터, 필터를 실행합니다. Problem은 redacted RFC 7807 형식의 tRPC 오류로 변환됩니다. 컨테이너 기반 provider 생성과 공개 API, 테스트, Problem 문서가 추가되었습니다. ChangestRPC 실행 파이프라인
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Client as tRPC Client
participant Router as createTrpcRouter
participant Context as TrpcExecutionContext
participant Pipeline as TrpcExecutionPipeline
participant Guard as Croco Guard
participant Interceptor as Croco Interceptor
participant Handler as Route Handler
participant Filter as Croco Exception Filter
Client->>Router: procedure 요청
Router->>Context: 실행 컨텍스트 생성
Router->>Pipeline: 가드 실행
Pipeline->>Guard: canActivate 호출
Pipeline->>Interceptor: 인터셉터 체인 실행
Interceptor->>Handler: route handler 호출
Handler-->>Interceptor: 결과 또는 오류 반환
Pipeline->>Filter: handler 오류 전달
Filter-->>Router: Problem 또는 원래 오류 반환
Router-->>Client: tRPC 오류 응답
Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
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. Comment |
📊 Benchmark Results✅ All benchmarks passed
Updated: 2026-08-04T14:47:55.466Z · Commit: a1fd0e6 |
7afb433 to
8bad615
Compare
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 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 `@packages/protocols-trpc/src/index.ts`:
- Around line 2-3: Reorder the exports in the module so the value export
TrpcExecutionContext appears before the type export TrpcRouterOptions. Keep both
exports unchanged and place all type exports after the value exports.
In `@packages/protocols-trpc/src/libs/createTrpcRouter.ts`:
- Around line 107-120: Update createProcedure’s setup around
createGuardAndFilterConfig and createInterceptors to resolve getGuards,
getFilters, and getInterceptors once during procedure construction, then reuse
those provider lists per request. Keep instantiateProvider inside the
request-time paths so container-scoped instantiation behavior remains unchanged.
- Around line 184-192: Update instantiateProvider to inspect provider.length
when options.container is absent and immediately throw a clear diagnostic
Problem if the provider declares constructor parameters, rather than casting it
to a zero-argument constructor and calling it without arguments. Preserve
container-based instantiation and zero-argument provider creation unchanged.
In `@packages/protocols-trpc/src/libs/TrpcExecutionContext.ts`:
- Around line 6-12: Update TrpcExecutionContext to accept a TContext generic,
type its trpcContext constructor field as TContext, and make getTrpcContext()
return TContext instead of unknown. Preserve the existing execution-context
behavior while propagating the typed context through all relevant declarations.
- Around line 40-49: Update readRequest to validate context.request,
context.req, and context as actual Fetch Request instances before returning
them, rather than accepting arbitrary objects through casts. Explicitly
normalize supported Node request objects into a Fetch Request, and route
unconstructable or invalid inputs through the established failure path instead
of returning an unsafe Request cast.
In `@packages/protocols-trpc/src/libs/TrpcExecutionPipeline.ts`:
- Around line 80-128: Extend TrpcExecutionPipeline.spec.ts with coverage for
both runFilters failure paths: a filter returning a non-4xx/5xx or otherwise
invalid result must record a CROCO_TRPC_FILTER_001 diagnostic with reason
"invalid-return", and a filter throwing must record the same diagnostic with
reason "thrown". Mock or inspect the runtime inspector to verify the event, and
assert the client receives the original error unchanged in both cases.
In `@packages/protocols-trpc/src/libs/TrpcProblemError.ts`:
- Around line 38-52: Update createTrpcFilterProblem to accept only RFC 7807
details with 4xx or 5xx status codes, in addition to matching the requested
status. Return undefined for 2xx, 3xx, or any other out-of-range status before
constructing TrpcFilterProblem, preserving the existing catch behavior.
In `@packages/protocols-trpc/src/tests/TrpcExecutionPipeline.spec.ts`:
- Around line 202-208: Update all three async denial assertions in
TrpcExecutionPipeline.spec.ts—around the `caller.trpcDeny.denied()` checks at
the referenced cases—to additionally verify the rejected error with
`rejects.toThrow()` while preserving the existing `rejects.toMatchObject` checks
for `code`, `cause.code`, and `status`. Ensure both error-throwing behavior and
structural details remain validated.
🪄 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: ASSERTIVE
Plan: Pro Plus
Run ID: ca98e6ad-dccf-4472-b8ca-a0ef2aea9f94
⛔ Files ignored due to path filters (2)
packages/problems-core/src/generated/problem-code-registry.tsis excluded by!**/generated/**pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (14)
.changeset/protocols-trpc-execution-pipeline.mddocs/problem-code-registry.jsonpackages/docs/src/content/docs/api/protocols-trpc/src/classes/TrpcExecutionContext.mdpackages/docs/src/content/docs/api/protocols-trpc/src/functions/createTrpcRouter.mdpackages/docs/src/content/docs/api/protocols-trpc/src/type-aliases/TrpcRouterOptions.mdpackages/docs/src/content/docs/en/reference/problem-recovery-cookbook.mdpackages/protocols-trpc/package.jsonpackages/protocols-trpc/src/index.tspackages/protocols-trpc/src/libs/TrpcExecutionContext.tspackages/protocols-trpc/src/libs/TrpcExecutionPipeline.tspackages/protocols-trpc/src/libs/TrpcProblemError.tspackages/protocols-trpc/src/libs/createTrpcRouter.tspackages/protocols-trpc/src/tests/TrpcExecutionPipeline.spec.tspublic-api-surface.snapshot.json
1dd3bc0 to
3e15dca
Compare
|
@coderabbitai resolve |
✅ Action performedComments resolved and changes approved. |
3e15dca to
64a5533
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@packages/protocols-trpc/src/libs/createTrpcRouter.ts`:
- Around line 128-150: Move createGuardAndFilterConfig() into the try block in
lifecycleProcedure so guard provider instantiation failures are handled by
rethrowFiltered() alongside runGuards() failures. Keep the existing context
creation and downstream procedure-result filtering behavior unchanged.
In `@packages/protocols-trpc/src/libs/TrpcExecutionContext.ts`:
- Around line 101-102: Update normalizeNodeRequest() so failures creating
Headers, URL, or Request are not converted to undefined; instead return or
propagate a distinct normalization diagnostic with a stable diagnostic code and
private evidence containing the underlying cause. Update readRequest() to
distinguish this normalization failure from genuinely unavailable requests and
avoid exposing URL, headers, or other sensitive values in the response.
In `@packages/protocols-trpc/src/tests/TrpcExecutionPipeline.spec.ts`:
- Around line 233-238: Change the test setup hook in the “tRPC Croco execution
pipeline” suite from afterEach to beforeEach so Container.reset() runs before
every test; keep the existing event and observedTrpcContext cleanup in the
appropriate per-test setup.
🪄 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: ASSERTIVE
Plan: Pro Plus
Run ID: a0c75207-ff15-4950-8904-748778cd4088
⛔ Files ignored due to path filters (2)
packages/problems-core/src/generated/problem-code-registry.tsis excluded by!**/generated/**pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (14)
.changeset/protocols-trpc-execution-pipeline.mddocs/problem-code-registry.jsonpackages/docs/src/content/docs/api/protocols-trpc/src/classes/TrpcExecutionContext.mdpackages/docs/src/content/docs/api/protocols-trpc/src/functions/createTrpcRouter.mdpackages/docs/src/content/docs/api/protocols-trpc/src/type-aliases/TrpcRouterOptions.mdpackages/docs/src/content/docs/en/reference/problem-recovery-cookbook.mdpackages/protocols-trpc/package.jsonpackages/protocols-trpc/src/index.tspackages/protocols-trpc/src/libs/TrpcExecutionContext.tspackages/protocols-trpc/src/libs/TrpcExecutionPipeline.tspackages/protocols-trpc/src/libs/TrpcProblemError.tspackages/protocols-trpc/src/libs/createTrpcRouter.tspackages/protocols-trpc/src/tests/TrpcExecutionPipeline.spec.tspublic-api-surface.snapshot.json
|
@coderabbitai resolve |
✅ Action performedComments resolved and changes approved. |
9c51d04 to
b371c22
Compare
b371c22 to
c42057c
Compare
Fixes #1674
Outcome
tRPC procedures now enter Croco's lifecycle pipeline before input parsing, so declared guards can deny a call before validation or handler execution. Class and method interceptors wrap controller invocation, while filters process guard, validation, interceptor, and handler failures in documented order.
Declared Problems and RFC 7807 filter results carry stable Croco code and status details through tRPC while private details and extensions stay redacted from wire messages and development stack data. Applications can provide their container through
TrpcRouterOptionsfor controller and lifecycle-provider resolution.Review focus
CROCO_TRPC_FILTER_001.Verification
pnpm --filter @croco/protocols-trpc test— 13 tests passed.pnpm --filter @croco/protocols-trpc typecheckpnpm --filter @croco/protocols-trpc lintpnpm --filter @croco/protocols-trpc buildpnpm public-api:checkpnpm docs:api:checkReview gates
Summary by CodeRabbit
새로운 기능
TrpcExecutionContext와 라우터 옵션을 공개 API로 제공합니다.문서