docs(billing): document meter service as calc-agnostic - #3798
Conversation
…st semantics stay downstream
|
Warning Review limit reached
More reviews will be available in 48 minutes and 15 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughDocumentation update to ChangesService Responsibility Clarification
🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
There was a problem hiding this comment.
Pull request overview
Documents the intended module boundary for billing metering by clarifying that billing.meter.service.js is calculation-agnostic (USD cost map → meter units via config ratios/knobs), and that downstream product-specific cost semantics should live downstream rather than being patched into the upstream service (to avoid being overwritten by /update-stack).
Changes:
- Adds a short “module boundary” note to
modules/billing/README.mdexplaining whatbilling.meter.service.jsdoes and does not do. - Explicitly documents the downstream-safe location for cost semantics and the
/update-stackoverwrite mechanism. - Recommends using default-off config knobs upstream instead of hardcoded downstream rules inside the service.
|
|
||
| `billing.meter.service.js` converts a feature-keyed **USD cost map → meter units** via config ratios (`dollarsToUnitRatio`, per-plan `ratios`) and applies config knobs (`runBase`, `maxUnitsPerOperation`). It does **not** know what a run costs. | ||
|
|
||
| **Downstream cost semantics — what a scrap/op costs, per-run infra base, product-specific floors/caps — live in the downstream's own cost module + config (e.g. Trawl `modules/costs`), never inline in this service.** An inline downstream patch here is silently wiped by `/update-stack`: a tier0 run-base floor added downstream inside a `billing.meter.service.js` copy was lost on the next stack sync, zero-ing metering for free-tier scrapes (trawl `#1293` → `#1316`). If a behaviour must live in this service, add it as a **default-off config knob**, never a hardcoded downstream rule. |
Per Copilot inline review: scrap/op → scrape/op (consistent with "scrapes" below), zero-ing → zeroing.
Why
billing.meter.service.jshas no downstream product knowledge by design — it only converts a USD cost map to meter units via config ratios. But this boundary was invisible, so downstream patches (per-run infra base, product floors/caps) kept landing inside the service copy on downstream repos, then getting silently wiped on the next/update-stacksync.Root incident: a tier0 run-base floor added inside
billing.meter.service.jsin Trawl was lost on the next stack sync → metering zeroed for free-tier scrapes (trawl#1293→#1316).What
6-line note added at the top of
modules/billing/README.md:Scope
Doc-only. No code change.
Summary by CodeRabbit