docs(admins): grants rows carry account_id; expires_at clamps to month end (chat#1948) - #296
Conversation
…h end (chat#1948) Two corrections found by verifying api#824 against the live preview, the step where the documented contract meets what the endpoint actually returns. - Each entry in the events `grants` array is the full stored grant row, so it carries `account_id`. The schema omitted it. It always equals the top-level `account_id`, but documenting only six of the seven fields makes the contract wrong rather than merely terse. - `expires_at` is now clamped to the last day of a short target month. The naive one-month add overflowed (Jan 31 -> Mar 3) and landed after the reset actually fires, so the API was over-promising the guarantee window by a day. The description now states the clamp and the direction of the remaining error: it can under-promise, never over-promise. Follows #295. Verified against api#824.
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Warning Review limit reached
Next review available in: 10 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: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
Two contract corrections found while verifying api#824 against its live preview — the step where the documented contract meets what the endpoint actually returns. Follows docs#295.
1.
grants[]rows carryaccount_idThe live response returns the full stored grant row:
{ "id": "357e7499-3949-417d-ae46-f4dffdf1fdda", "account_id": "4eb56302-2f6d-4c68-ae52-769727a03e23", "granted_by": "fb678396-a68f-4294-ae50-b8cacf9ce77b", "reason": "Zeroing out the test account", "previous_credits": 250, "remaining_credits": 0, "created_at": "2026-08-06T23:44:40.179605+00:00" }The schema documented six of those seven fields.
account_idis redundant in context — it always equals the top-levelaccount_id, since the endpoint reports on one account at a time — but omitting it makes the contract wrong rather than merely terse, so it is documented with that redundancy explained.2.
expires_atclamps to the end of a short monthapi#824 changed the underlying computation, and this brings the description in line.
The naive one-month add overflowed for month-end grants: a Jan 31 grant produced Mar 3. That is after the reset actually becomes eligible (around Mar 2), so the API was telling an admin the balance was safe for a day longer than it was. Since the field is defined as "the point after which the balance is no longer guaranteed", erring late is the one direction that actively misleads.
It now clamps to the last day of the target month (Jan 31 → Feb 28), which is at or before the real reset in every case tested. The description states the clamp and the direction of the residual error: it can under-promise by up to a day, never over-promise.
Verification
accounts.jsonparses; all$refs resolve;grantsrequired list goes 6 → 7. Theaccount_idshape above is copied from a real preview response, not composed by hand.Summary by cubic
Aligns the admins credits docs with the live API: each
grants[]entry includesaccount_id, andexpires_atis clamped to the end of the target month for short months.account_idtogrants[]and marked it required; it matches the top-levelaccount_id.expires_atdescription: one month aftergranted_at, clamped to the target month’s last day (e.g., Jan 31 → Feb 28); it never over-promises the guarantee window.Written for commit 628aed5. Summary will update on new commits.