subscription.cancelled sync fails: duplicate unique id across persisted lines and charges with enable_credit_then_invoice: true

[pratham-ez]

Title

subscription.cancelled sync fails with duplicate unique id across persisted lines and charges when credits.enable_credit_then_invoice: true

---

Environment

• OpenMeter version: 10f948f17 (staging billing-worker image)
• Config:
  • credits.enabled: true
  • credits.enable_credit_then_invoice: true
  • events.enabled: true
• Settlement mode: Plans use default credit_then_invoice (usage-based rate cards only — standard + premium features)
• Billing profile: Custom Invoicing (send_invoice), collection interval PT5M
• Workers running: billing-worker, sink-worker, jobs/cron

---

Summary

With enable_credit_then_invoice: true, the first subscription sync succeeds (charges + gathering mirror lines are created). Any subsequent sync (cancel, cron resync, plan change) fails in persistedstate.Loader.LoadForSubscription because the same unique_reference_id exists in both billing_invoice_lines (charge-backed gathering mirror) and charges.

The cancel event retries 9 times and lands in DLQ. The gathering invoice is never trimmed to activeTo, and no standard invoice is cut from the native cancel path.

---

Reproduction

1. Enable credits.enabled: true and credits.enable_credit_then_invoice: true.
2. Create a customer with subjectKeys = org UUID.
3. Issue a credit grant (e.g. $10).
4. Create a subscription on a credit_then_invoice plan with two usage-based rate cards (e.g. synqed_feature_standard @ $2/unit, synqed_feature_premium @ $1/unit).
5. Wait for billing-worker initial sync (~seconds) — succeeds; gathering invoice + charges are created.
6. Optionally ingest usage events via POST /api/v1/events (CloudEvents with TOOL_CALL_STANDARD / TOOL_CALL_PREMIUM).
7. Cancel immediately via OpenMeter only (no force invoice):
   
8. Observe billing-worker logs.

---

Observed error

synchronize subscription: duplicate unique id across persisted lines and charges:

  01KSA6NP21H4EYBP2KB4QNZKC6/default/synqed_feature_premium/v[0]/period[0]

Full log context:

{

  "ts": "2026-05-23T10:46:11Z",

  "level": "WARN",

  "caller": "openmeter/watermill/router/logger.go:40",

  "msg": "Error occurred, retrying",

  "service.name": "openmeter-billing-worker",

  "service.version": "10f948f17",

  "retry_no": 6,

  "max_retries": 9,

  "error.message": "synchronize subscription: duplicate unique id across persisted lines and charges: 01KSA6NP21H4EYBP2KB4QNZKC6/default/synqed_feature_premium/v[0]/period[0]"

}

 

After 9 retries → Failed to process message, message is going to DLQ on topic io.openmeter.subscription.v1.subscription.cancelled.

---

Concrete example (staging)

Field	Value
Subscription	01KSA6NP21H4EYBP2KB4QNZKC6
Customer	01KSA61A2R80VXA83SB658GPNQ
Subject key	9520ea79-2aaa-4310-8b53-6e24d46e743c
Gathering invoice	01KSA6NPA8SK4VK980SVHG6NNB
Cancel time	2026-05-23T10:46:11Z
activeTo	2026-05-23T10:46:11.178439Z

---

What we are NOT doing

• Not using Synqed ops cancel (which calls ForceInvoiceCustomer with progressiveBillingOverride: true)
• Not manually calling POST /api/v1/billing/invoices/invoice or /advance
• No custom renewal-grant code deployed on staging

This reproduces on stock OpenMeter with the documented credit_then_invoice config.

---

Impact

• Any subscription with enable_credit_then_invoice: true breaks on the second billing-worker sync (cancel, renewal, cron subscription-sync, plan edit).
• Cancel sync never completes → gathering invoices stay stale → native partial-period invoicing at cancel does not work.
• DLQ fills with subscription.cancelled events.
• Workaround today: ops force invoice on cancel (bypasses sync) — not acceptable for production customer flows.

POST /api/v1/subscriptions/{subscriptionId}/cancel

{"timing": "immediate"}

 

[GAlexIHU]

Hey @pratham-ez

Sorry for not picking this up earlier. We are not doing a great job of documenting feature readiness in OpenMeter GH so its on us, but that feature was mid-development and unstable (far before pre-release). It has since been completed & should be working correctly now.

Until we start doing a better job of documenting these here I suppose the rule of thumb would be to follow the Kong Konnect announcements for feature readiness: features marked as public beta or GA there are expected to work here as well (when the feature is present in OpenMeter)