fix(billing): advance credit overdraft invoice window past last invoiced range

[rohilsurana]

Problem

GenerateForCredits computes the invoice window start from the last credit overdraft invoice with this condition:

if item.TimeRangeEnd != nil && item.TimeRangeStart.Before(startRange) {
    startRange = *item.TimeRangeEnd
}

It compares the anchor item's start against the customer's creation time. That is only true for an invoice whose window began at creation — and even then only because providers store item ranges in whole seconds, truncating the creation timestamp's sub-second part. Any later invoice starts after creation, the condition is false, and the window snaps back to the customer's creation time.

Since #1502 excluded overdraft payment credits from the range balance, a snapped-back window counts all previously invoiced usage again. Combined with #1498 (anchor = newest invoice), the result alternates: one tick produces the correct invoice, the next tick anchors on it, snaps back, and bills the customer's entire history as a duplicate.

Observed in a deployment: a customer expecting one $386 invoice on Jul 1 received $386 (correct window) at 00:02 and $2,756 (= all usage since account creation, including two already-paid invoices) at 00:07, one sync tick later.

Two more defects in the same block:

• The alreadyInvoiced equality check compares against startRange after the same item mutated it, so it can never match a single-item invoice; same-day dedup only worked by accident via the empty-window balance.
• item.TimeRangeStart.Before(...) is dereferenced with only TimeRangeEnd nil-checked — an item with a null range_start panics the whole sync tick.

Fix

Extract the window computation into computeOverdraftWindow and base it solely on TimeRangeEnd:

• advance the window start to the anchor item's TimeRangeEnd whenever that end is after the current start,
• report alreadyInvoiced when the anchor's end already reaches the current range end,
• skip items without TimeRangeEnd instead of dereferencing a possibly-nil TimeRangeStart.

Tests

Table-driven tests for computeOverdraftWindow covering: no prior invoice, first-invoice anchoring (both truncated and whole-second creation times), later-invoice anchoring (the snap-back reproduction), same-day rerun dedup, and nil range start/end. The snap-back, whole-second, same-day, and nil-start cases fail on the previous logic (the nil-start case panicked).

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
frontier	Ready	Preview, Comment	Jul 2, 2026 11:37am

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c888d031-08b1-4350-bdd6-f43f1cde842a

📥 Commits

Reviewing files that changed from the base of the PR and between 4a8d725 and 3dae1e9.

📒 Files selected for processing (2)

• billing/invoice/service.go
• billing/invoice/service_test.go

👮 Files not reviewed due to content moderation or server errors (2)

• billing/invoice/service_test.go
• billing/invoice/service.go

---

📝 Walkthrough

[!WARNING]

Walkthrough skipped

File diffs could not be summarized.

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coveralls]

Coverage Report for CI Build 28587052787

Coverage increased (+0.03%) to 44.865%

Details

• Coverage increased (+0.03%) from the base build.
• Patch coverage: 1 uncovered change across 1 file (14 of 15 lines covered, 93.33%).
• 1 coverage regression across 1 file.

Uncovered Changes

File	Changed	Covered	%
billing/invoice/service.go	15	14	93.33%

Coverage Regressions

1 previously-covered line in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
billing/invoice/service.go	1	7.9%

---

Coverage Stats

Relevant Lines:	37608
Covered Lines:	16873
Line Coverage:	44.87%
Coverage Strength:	12.49 hits per line

---

💛 - Coveralls