Need Help Debugging Entitlement Grant value Not Reducing After Successfull Event Ingestion

[Sujitha-Ramanathan]

Preflight Checklist

• I have searched the issue tracker for an issue that matches the one I want to file, without success.
• I am not looking for support or already pursued the available support channels without success.

OpenMeter Version

1.0.0

Expected Behavior

Hi team, I’m seeing that my events are being ingested successfully with no failures, but the corresponding entitlement credits are not getting deducted. Can you help me understand how to debug why the usage isn’t applying to the entitlement?

It would be helpful to know:
Where to check logs or evaluation traces for entitlement consumption.

org : consumption-hackathon
meter : PriorityMeter
feature : featurehighpriority
Customer: ExistingFeatureUsageConsumptionTest

sample event sent:
{
"specversion": "1.0",
"type": "priorityCredits",
"id": "existingfeatureevent1",
"time": "2025-12-09T09:11:19.885Z",
"source": "my-app",
"subject": "euser1",
"data": {
"priorityCredits": "1",
"sku": "skp"
}
}

expected :
the usage value reduced from the customer's entitlement grant for that feature.

Actual Behavior

The grant value did not reduce

Steps To Reproduce

No response

Additional Information

No response

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and agent prompts for this issue.

• Create Plan

Examples

• Example 1
• Example 2

🔗 Similar & Duplicate Issues

Related Issues

• openmeterio/openmeter#3200
• openmeterio/openmeter#3146
• openmeterio/openmeter#3293
• openmeterio/openmeter#2721

👤 Suggested Assignees

• followbtb
• tollercode
• GAlexIHU
• superphao4

---

🧪 Issue enrichment is currently in early access.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

[GAlexIHU]

Hi @Sujitha-Ramanathan

From a bird's eye view

• First, events are ingested (POST /api/v1/events or bulk insert) - for recent versions we no longer do schema validations here so events should always get through
  • you can validate this happened with kafbat to see your messages on the ingest topic
• sink-worker writes them to storage (clickhouse)
  • after this they will shop on in meter queries
• when an entitlement's value is queried the live usage values are read from CH (along with other stuff from PG) --
  • as time passes we keep "partial calculations" in postgres to speed things up, they are in the balance_snapshots table, but it is a heuristic process so not finding any values in that table doesnt necessarily mean something's wrong
• if the usage shows up as attributed to the meter and the feature then next step would be to check the timing of the entitlement and the grants. During the period for which usage was reported
  • is the entitlement active?
  • are the grants active?

If everything checks out we can try take a look if you can share an anonymized/sanitized export of the relevant entities (example events, meters, features, entitlements, grants, usage_resets, balance_snapshots)

Q: Whats the exact OpenMeter version you're using? For the general debugging steps it doesn't make a significant difference, but if you encountered a bug it might already be fixed in later releases.

[Sujitha-Ramanathan]

Hi Alex, Thanks for the overview!!! We’re using the OpenMeter Cloud instance, and the version isn’t exposed through the UI or any of the available APIs When I sent the usage event, the entitlement and grants for the customer were active. I’ll share the entities I used in this test setup. Could you take a look? *Org:* consumption-hackathon *Meter:* PriorityMeter *Feature:* featurehighpriority *Customer:* ExistingFeatureUsageConsumptionTest *Sample event sent*: { "specversion": "1.0", "type": "priorityCredits", "id": "existingfeatureevent1", "time": "2025-12-09T09:11:19.885Z", "source": "my-app", "subject": "euser1", "data": { "priorityCredits": "1", "sku": "skp" } } *Expected behavior* The usage should reduce the customer's entitlement grant for that feature. *Actual behavior* The grant value did not reduce.

…

On Tue, Dec 9, 2025 at 4:21 PM Alex Goth ***@***.***> wrote: *GAlexIHU* left a comment (openmeterio/openmeter#3678) <#3678 (comment)> Hi @Sujitha-Ramanathan <https://github.com/Sujitha-Ramanathan> From a bird's eye view - First, events are ingested (POST /api/v1/events or bulk insert) - for recent versions we no longer do schema validations here so events should always get through - you can validate this happened with kafbat to see your messages on the ingest topic - sink-worker writes them to storage (clickhouse) - after this they will shop on in meter queries - when an entitlement's value is queried the live usage values are read from CH (along with other stuff from PG) -- - as time passes we keep *"partial calculations"* in postgres to speed things up, they are in the balance_snapshots table, but it is a heuristic process so not finding any values in that table doesnt necessarily mean something's wrong - if the usage shows up as attributed to the meter and the feature then next step would be to check the timing of the entitlement and the grants. During the period for which usage was reported - is the entitlement active? - are the grants active? If everything checks out we can try take a look if you can share an anonymized/sanitized export of the relevant entities (example events, meters, features, entitlements, grants, usage_resets, balance_snapshots) Q: Whats the exact OpenMeter version you're using? For the general debugging steps it doesn't make a significant difference, but if you encountered a bug it might already be fixed in later releases. — Reply to this email directly, view it on GitHub <#3678 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BT7WYJ6ON2QBWAM5CMWPZKL4A2STHAVCNFSM6AAAAACOPJFTBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMZRGU3TGMRSGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Sujitha-Ramanathan]

Hi @GAlexIHU

any updates on the above issue?