#uni_api
1 messages ¡ Page 1 of 1 (latest)
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1441431658224943155
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
I'll add the exact error response here as well, that started appearing on the 4th of November.
Cannot create a usage record for si_SK14uqVnjpyGYx because it is not on the legacy metered billing system. Call /v1/billing/meter_events instead.
And what essentially happened, is it started attaching the metered amount we posted to every single customer we have (85 subscriptions in total were affected)
If you want I can also find multiple invoices with identical values as examples.
Hi there, juggling a couple of threads but will begin investigating this!
Ok, I'll be around
You mentioned "it started attaching the metered amount we posted to every single customer we have". Is there a separate request related to this?
So. Every time a request like this was sent, it returned an error.
In addition to returning the error, it also set the metered number in each subscription we have with that "price/product" to the same number
So lets say we sent a request that said: set meter X to value Y.
It would set the same product in every subscription metered count to Y
And it still does that. We had to manually remove the metered products from all of our subscriptions as a temporary fix until we can figure this out
I will show you 2 invoices from today:
in_1SVqC8DpBXyqTWRCysSegAyI
in_1SVdnODpBXyqTWRCnOYntY3x
Both have "VALUE MONITORING METERED" product count set to 42
None of the requests we sent have set these customers to a count of 42. We do have another customer with that count.
So to sum it up.
The endpoint returns an error. But in addtion to returning that error, it also still sets the metered count on everything (instead of that specific one) that has the same product (price by your terminology) attached.
What I'm guessing is, someone made a migration and deprecated something. But did it in a way that is causing pretty nasty problems with invalid billing
Got it, thanks for the additional context. Looking into this now
This is what I've found so far. For https://dashboard.stripe.com/acct_1HUXQHDpBXyqTWRC/invoices/in_1SVqC8DpBXyqTWRCysSegAyI
This is the successful POST /v1/subscription_items/si_TH9i2ZCz0I6UEG/usage_records request with a quantity of 43
https://dashboard.stripe.com/acct_1HUXQHDpBXyqTWRC/logs/req_ZUPjQzDz7WHH50
So that invoice doesn't seem related to the failed requests you mentioned
There are a few hundred failed requests starting November 4th and about 80 subscriptions. So I didn't correlate them specifically.
The same flow worked correctly until around september. (First invoices I spotted after investigating that mismatch our own data).
The flow with the Java SDK is the following for each subscription.
String meteredItem = subscription.getItems().getData().get(2).getId();
long timestamp = Instant.now().getEpochSecond();
Map<String, Object> params = new HashMap<>();
params.put("quantity", count);
params.put("timestamp", timestamp);
params.put("action", "set");
UsageRecord usageRecord =
UsageRecord.createOnSubscriptionItem(
meteredItem,
params,
null
);
Frankly I can't think of a reason this would happen.
But wait. Why are some of these requests failing and others are not? The subscription structure is all identical?
I'm stepping in now! looks like there has been some back and forth, lets start fresh:
@winter tulip can you summarize pls where you left off?
I'll review the logs based on what @shell shale linked me. And I'll get back to this once I have a better picture of what is actually happening. I wan't to compare it to our own logs so I can be more specific.
Right now its a "vague" problem
gotcha
So feel free to close this for now, I can start a new thread once I have specific examples from logs.