Skip to content

fix(metering,health): dedupe metered usage on retry (#1151) and bound health-check cron (#1152) - #1190

Open
ayomidearegbeshola29-dev wants to merge 3 commits into
StellerCraft:mainfrom
ayomidearegbeshola29-dev:fix/craft-1151-1152
Open

fix(metering,health): dedupe metered usage on retry (#1151) and bound health-check cron (#1152)#1190
ayomidearegbeshola29-dev wants to merge 3 commits into
StellerCraft:mainfrom
ayomidearegbeshola29-dev:fix/craft-1151-1152

Conversation

@ayomidearegbeshola29-dev

@ayomidearegbeshola29-dev ayomidearegbeshola29-dev commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Summary

Resolves #1151 and #1152

#1151 — Duplicate metered usage on retry

  • MeteringService.recordUsage now accepts an optional logical idempotencyKey.
  • When a stable key is supplied (e.g. the payment idempotency key for a checkout), a replayed event returns the existing usage record without incrementing quantity, preventing duplicate metered billing even when the retry lands in a different one-second window.
  • The legacy one-second-granularity keying is preserved for plain API-call tracking (with-usage-tracking.ts), so genuinely distinct calls still accumulate.
  • MeteringPaymentIntegration.reportUsage threads the key through.

#1152 — Health-check cron time budget

  • HealthMonitorService gains checkAllDeploymentsPaged({ cursor, limit }) returning { results, nextCursor, totalProcessed } (ordered by id).
  • The cron health-check route now pages through deployments, resuming via cursor and stopping once HEALTH_CHECK_BUDGET_MS (default 60_000ms) is exceeded, so a single sweep can no longer run unbounded / time out.
  • checkAllDeployments() is kept (deprecated) for backward compatibility.

Test plan

  • Added metered-billing.integration.test.ts asserting exactly one usage row is inserted for a retried checkout across a second boundary and that quantity is not incremented.
  • Updated route.test.ts to mock the new paged method.
  • Note: backend has no local node_modules, so CI must run vitest for the backend suite.

closes #1152

ChainBid Developer and others added 3 commits August 28, 2026 10:48
… and bound health-check cron (StellerCraft#1152)

StellerCraft#1151: thread an optional logical idempotency key through reportUsage ->
MeteringService.recordUsage. When a stable key is supplied (e.g. the payment
idempotency key for a checkout), a replayed event returns the existing usage
record WITHOUT incrementing quantity, preventing duplicate metered billing
across second boundaries. Legacy one-second-granularity keying is preserved
for plain API-call tracking.

StellerCraft#1152: HealthMonitorService gains checkAllDeploymentsPaged({cursor, limit})
that returns { results, nextCursor, totalProcessed }. The cron health-check
route now pages through deployments, resuming via cursor and stopping once the
configured HEALTH_CHECK_BUDGET_MS (default 60s) is exceeded, so a single sweep
can no longer run unbounded / time out. checkAllDeployments() is kept for
backward compatibility.
… persist checkpoint (StellerCraft#1152)

- HealthMonitorService.checkAllDeploymentsPaged now runs its page's health
  checks through a bounded concurrency pool (default 10) instead of an
  unbounded Promise.all, so a large fleet stays within the cron budget.
- Add getCheckpoint/saveCheckpoint backed by a new cron_checkpoints table
  (migration 014). The cron route resumes from the persisted cursor on the
  NEXT invocation, so a sweep truncated by the platform execution limit
  continues where it left off rather than restarting from the top.
- Add health-check.cascade.integration.test.ts: a 500-deployment fleet
  completes within the documented budget, and a budget-truncated run
  checkpoints progress and resumes with every deployment checked exactly once.
- route.test.ts updated for the new checkpoint calls.

Co-authored-by: ayomide
@drips-wave

drips-wave Bot commented Aug 28, 2026

Copy link
Copy Markdown

@ayomidearegbeshola29-dev Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant