fix: document deployment recipes for supported runtimes - #882
Conversation
|
Warning Review limit reached
More reviews will be available in 21 minutes and 43 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. 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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (24)
📝 WalkthroughWalkthroughAWS Lambda, Cloudflare Workers, Node 서버 배포 레시피를 담은 신규 가이드 문서( ChangesDeployment Recipes 가이드 신규 추가
LLM Metering 타입·API 참조 문서 개선
추정 코드 리뷰 노력🎯 2 (Simple) | ⏱️ ~12 minutes 연관 가능성이 있는 PR
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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❌ Some benchmarks failed Gate failures
Updated: 2026-06-18T12:32:48.567Z · Commit: b2366ae |
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/docs/src/content/docs/api/llm-metering/src/type-aliases/ModelPricing.md (1)
20-40: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
ModelPricing문서에서 새 프로퍼티에 대한 설명 누락.새로 추가된
effectiveDate?와source?프로퍼티는 타입 정의만 있고 한국어 설명이 없습니다. 비교하면, 같은 PR에서 추가된PricingRegistryEntry,PricingRegistryDefinition문서들은 상단에 "비용 예산, 모델 단가, 사용량 기록 타입입니다." 같은 설명을 포함하고 있습니다.각 프로퍼티의 용도(예:
effectiveDate는 가격 적용 시작 날짜,source는 가격 데이터 출처 등)에 대한 설명을 추가하는 것이 문서의 명확성을 높일 것입니다.🤖 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 `@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/ModelPricing.md` around lines 20 - 40, The ModelPricing type documentation is missing explanatory descriptions for the newly added optional properties effectiveDate and source. Add clear Korean language descriptions for each of these properties explaining their purpose and usage, similar to the documentation style used in the related PricingRegistryEntry and PricingRegistryDefinition type definitions in the same PR. For effectiveDate, describe when the pricing becomes effective, and for source, describe where the pricing data originates from.
🤖 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/docs/src/content/docs/api/llm-metering/src/classes/PricingTable.md`:
- Around line 154-176: The fromRegistry() method is not preserving optional
metadata fields that are included during serialization in toRegistry().
Specifically, when reconstructing ModelPricing objects from
PricingRegistryDefinition entries, the source and effectiveDate fields are being
lost. Update the fromRegistry() method to copy all fields from the registry
entries, including the optional source and effectiveDate fields in addition to
the currently copied inputPricePerToken, outputPricePerToken, and currency
fields. This will ensure round-trip conversion (PricingTable →
PricingRegistryDefinition → PricingTable) preserves all metadata without loss.
In
`@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeterId.md`:
- Line 10: The description of the LlmMeterId type in the markdown documentation
is inaccurate. The current description on line 10 describes it as relating to
cost budgets, model unit prices, and usage records, but LlmMeterId is actually a
union type of metric identifiers (PROMPT_TOKENS, COMPLETION_TOKENS,
EMBEDDING_TOKENS, COST_USD) used for metering. Replace the inaccurate
description with a more precise one that reflects LlmMeterId is a metric
identifier type for LLM usage metering, such as "LLM 사용량 메트릭 식별자 타입입니다" or "토큰 및
비용 메터링을 위한 메트릭 종류입니다".
In
`@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeteringFailurePolicy.md`:
- Around line 8-10: The description for LlmMeteringFailurePolicy on line 10 is
inaccurate and describes cost budgets and usage records instead of the actual
purpose. Replace the existing description with text that accurately reflects
that LlmMeteringFailurePolicy defines the handling policy when LLM metering
operations fail, such as "메터링 실패 시 처리 정책을 지정하는 타입입니다" or similar wording that
clearly indicates this type is about failure handling behavior rather than
billing or cost information.
In
`@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeterUsageDelta.md`:
- Line 10: The description for the LlmMeterUsageDelta type in the documentation
is generic and does not accurately reflect that this type represents metering
usage delta (changes/increments). Replace the current description "비용 예산, 모델 단가,
사용량 기록 타입입니다." with a more specific description that clarifies this type
represents metering usage deltas, such as "메터링 사용량 변화(delta)를 나타내는 타입입니다." Also
apply the same fix to the LlmMeterId.md documentation which has an identical
generic description that needs to be made more specific to its actual purpose.
- Around line 20-22: Remove the unused "stream" operation value from the
operation field type definition in the LlmMeterUsageDelta type alias
documentation since it is not actually used in the codebase. Update the
operation field to only include the currently supported values "generate",
"embed", and "cost_tracking" while keeping the "| string" union type to indicate
that additional operation types can be added in the future. Alternatively, add
clarifying documentation that explicitly states which operation values are
currently supported versus which are reserved for future use.
In
`@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmQuotaPolicyContext.md`:
- Line 10: Update the description of the LlmQuotaPolicyContext type alias
documentation to accurately reflect its purpose. Replace the current description
that incorrectly refers to cost budget, model unit price, and usage records with
a description that explains LlmQuotaPolicyContext is a context object required
for quota policy enforcement execution, containing fields such as tenantId,
modelId, provider, operation, idempotencyKey, meters, and optional metadata.
In
`@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryEntry.md`:
- Line 8: The PricingRegistryEntry type alias definition in the documentation
currently shows ModelPricing & object which is too generic and inaccurate.
Update the type definition on line 8 to explicitly show the actual object
structure: replace object with { modelId: string; provider: string; } so the
documentation accurately reflects that PricingRegistryEntry is ModelPricing
intersected with an object containing modelId and provider string properties.
In
`@packages/docs/src/content/docs/api/llm-metering/src/variables/samplePricingRegistry.md`:
- Line 20: The type annotation for the entries field in the
samplePricingRegistry documentation is incorrectly marked as object[] on line
20. Update the documentation to reflect the actual type definition from
PricingRegistryDefinition, which specifies that the entries field should be
typed as readonly PricingRegistryEntry[] rather than object[]. This accurately
represents that each item in the entries array is a PricingRegistryEntry object
containing provider, modelId, inputPricePerToken, outputPricePerToken, and
currency properties.
---
Outside diff comments:
In
`@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/ModelPricing.md`:
- Around line 20-40: The ModelPricing type documentation is missing explanatory
descriptions for the newly added optional properties effectiveDate and source.
Add clear Korean language descriptions for each of these properties explaining
their purpose and usage, similar to the documentation style used in the related
PricingRegistryEntry and PricingRegistryDefinition type definitions in the same
PR. For effectiveDate, describe when the pricing becomes effective, and for
source, describe where the pricing data originates from.
🪄 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
Run ID: b1bd9f9a-be4e-4649-8a3a-a34fc836abf8
📒 Files selected for processing (24)
packages/docs/README.mdpackages/docs/astro.config.mjspackages/docs/src/content/docs/api/llm-metering/src/classes/LlmMeteringService.mdpackages/docs/src/content/docs/api/llm-metering/src/classes/PricingRegistryConflictProblem.mdpackages/docs/src/content/docs/api/llm-metering/src/classes/PricingTable.mdpackages/docs/src/content/docs/api/llm-metering/src/interfaces/LlmQuotaPolicy.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeterId.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeterUsageDelta.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeteringFailurePolicy.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeteringServiceOptions.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmQuotaPolicyContext.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/ModelPricing.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryDefinition.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryEntry.mdpackages/docs/src/content/docs/api/llm-metering/src/variables/samplePricingRegistry.mdpackages/docs/src/content/docs/api/problems-core/src/classes/Problem.mdpackages/docs/src/content/docs/api/testing/src/functions/createLlmProviderConformanceSuite.mdpackages/docs/src/content/docs/api/testing/src/type-aliases/LlmProviderConformanceCase.mdpackages/docs/src/content/docs/api/testing/src/type-aliases/LlmProviderConformanceOptions.mdpackages/docs/src/content/docs/api/testing/src/type-aliases/LlmProviderConformancePromptSet.mdpackages/docs/src/content/docs/api/testing/src/type-aliases/LlmProviderConformanceSuite.mdpackages/docs/src/content/docs/en/guides/deployment-recipes.mdxpackages/docs/src/content/docs/en/guides/getting-started.mdxpackages/docs/src/content/docs/en/index.mdx
92f466d to
c6b235c
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
packages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryEntry.md (1)
8-8:⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
PricingRegistryEntry타입 정의를 더 명확하게 표현하세요.라인 8의
ModelPricing & object는 과도하게 일반화되어 있습니다. 실제 타입 정의는 다음과 같습니다:ModelPricing & { provider: string; modelId: string; }문서의 타입 표현을
ModelPricing & { modelId: string; provider: string }으로 업데이트하면, 독자가 정확한 구조를 한눈에 파악할 수 있습니다. Type Declaration 섹션의 필드 설명은 정확하지만, 라인 8의 타입 선언이 명확성을 해치고 있습니다.🤖 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 `@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryEntry.md` at line 8, The PricingRegistryEntry type definition currently uses an overly generic object type that doesn't clearly convey the actual structure. Replace the type declaration from ModelPricing & object to ModelPricing & { modelId: string; provider: string } to explicitly show the object properties that are part of the PricingRegistryEntry type, making the structure immediately clear to readers without requiring them to look at additional sections.
🤖 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/docs/src/content/docs/en/guides/deployment-recipes.mdx`:
- Around line 382-388: There is an inconsistency between the health endpoints
mentioned in the Node boundary section (lines 384-385 recommending
`/health/live` and `/health/ready` or `/ready` endpoints) and the Lambda
`createDeploymentApp()` example (lines 152-155) which only implements
`/api/health`. Either clarify in the Node boundary section that developers must
explicitly implement the `/health/live` and `/health/ready` endpoints themselves
based on their needs, or add implementations of these endpoints to the example
`app.ts` to provide a complete, ready-to-use reference for developers following
this deployment guide.
---
Duplicate comments:
In
`@packages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryEntry.md`:
- Line 8: The PricingRegistryEntry type definition currently uses an overly
generic object type that doesn't clearly convey the actual structure. Replace
the type declaration from ModelPricing & object to ModelPricing & { modelId:
string; provider: string } to explicitly show the object properties that are
part of the PricingRegistryEntry type, making the structure immediately clear to
readers without requiring them to look at additional sections.
🪄 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
Run ID: 9293022b-ebf4-4f93-a03d-27737dd7be51
📒 Files selected for processing (24)
.changeset/ccef902c.mdpackages/docs/README.mdpackages/docs/astro.config.mjspackages/docs/src/content/docs/api/llm-metering/src/interfaces/LlmQuotaPolicy.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmCostBudget.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmEmbeddingUsageRecord.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeterId.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeterUsageDelta.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmMeteringFailurePolicy.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmQuotaPolicyContext.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/LlmUsageRecord.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/ModelPricing.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryDefinition.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/PricingRegistryEntry.mdpackages/docs/src/content/docs/api/llm-metering/src/type-aliases/UsageAccuracy.mdpackages/docs/src/content/docs/api/llm-metering/src/variables/samplePricingRegistry.mdpackages/docs/src/content/docs/en/guides/deployment-recipes.mdxpackages/docs/src/content/docs/en/guides/getting-started.mdxpackages/docs/src/content/docs/en/guides/runtime-contract.mdxpackages/docs/src/content/docs/en/index.mdxpackages/llm-metering/src/index.tspackages/llm-metering/src/libs/PricingTable.tspackages/llm-metering/src/libs/types.tspackages/llm-metering/src/tests/PricingTable.spec.ts
💤 Files with no reviewable changes (1)
- packages/llm-metering/src/index.ts
5a395d1 to
18fab11
Compare
Fixes #854.
Summary
The public docs now include a deployment recipe guide for the supported Croco runtime entries: AWS Lambda HTTP API, Cloudflare Workers fetch handlers, and long-lived Node servers.
The guide gives a copy-ready Lambda baseline with environment validation, app bootstrap, module-scope telemetry initialization,
forceFlush()criteria, and explicit Lambda boundaries. It also documents Worker configuration withnodejs_compat, Worker-specific config and unsupported Node APIs, plus Node server defaults for health, readiness, signal handling, and telemetry shutdown.The docs landing page, sidebar, getting-started next steps, and docs README now link to the new guide. This branch also commits generated API reference output required by CI's docs-sync check.
Verification
pnpm --filter @croco/docs docs:build- passed; generated/en/guides/deployment-recipes/successfully.pnpm turbo run docs:build --force- passed; matches the CI docs-sync generation command.pnpm check- passed.pnpm changeset-required:check -- --base origin/trunk --head HEAD- passed with no publishable package behavior changes detected.pnpm first-success:verify- passed.git diff --checkandgit diff --cached --check- passed.pnpm test201/201 tasks and fullpnpm typecheck200/200 tasks.Self-review gates
nodejs_compat, and no changeset is required.packages/docs/src/content/docs/apito matchpnpm docs:buildoutput.Risk
Low. This is documentation-only and was validated by the docs build plus full pre-push test/typecheck gates.
Summary by CodeRabbit
릴리스 노트