#philipp_api
dim jasperBOT
👋 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/1334604346041569330
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
formal pollenBOT
arctic fossil
Have to add one weird thing. Randomly it works in the next month. 😅
near reef
Hi there 👋 offhand I'm not thinking of a limitation preventing you from testing meters in a test clock scenario.
Can you share more context on what you mean when you say the data isn't taken into account in the upcoming invoice? Are you retrieving the upcoming invoice to see that, or are you looking at something in the dashboard (or possibly something else)?
arctic fossil
Hi toby,
Thanks for helping!
I'm advancing the clock to a time after the invoice finalization event and look at the payed invoice in the dashboard. I triggered 1 meter event before so my amount should be 1 but it is 0. Sometimes the invoice of the next peroid or the invoice after it shows the 1 licence, I wanted to see in the first one. It's really strange and I find no systematic behaviour in it.
near reef
Do you have those Invoice IDs?
arctic fossil
invoice march in_1Qn0KdG3yyC68CM0SDzEpF5I -> 25,70 should be 40,70
invoice april in_1Qn0PZG3yyC68CM0iOHGsGOl -> 40,70 is correct
meter was triggered before the march and april invoice finalization (at invoice upcoming)
Sometimes it needs two months to respect the meter events. Checked all ids twice, I'm pretty sure I'm watching at the correct items.
near reef
Gotcha, taking a closer look at the timing there.
arctic fossil
ok, thanks :)
mtr_test_61RQsNY3Hmb4CWfb441G3yyC68CM0NbE (the meter object if it helps)
clock_1Qn028G3yyC68CM0nvxyxIbc (the clock)
cus_RgMkA4UqrrSrgv (the customer)
in_1Qn0RfG3yyC68CM0JKSiPmTa (may invoice) is as expected.
near reef
Sorry, hang on. I already have enough objects, and need some time to piece together the exact order that things happened in.
arctic fossil
Sorry, only wanted to provide all data. I think it's all I got.
near reef
Okay, looks like you're probably waiting for the test_helpers.test_clock.ready before creating the meter event
arctic fossil
Yes, currently I do the tests manually with the dashboard and my server and wait until the clock is ready. The next step to integrate it into a unit test, but first I wanted to figure out if it's possible. I didn't find any docs about testing usage based billing in context with subscriptions.
near reef
Let's try to step through this.
For this meter event creation request:
https://dashboard.stripe.com/test/logs/req_VDLG8I6tZz0yCz
Which Invoice did you expect to see that on? I see the test clock was frozen at a time on March 31st 2025 when that request was made.
arctic fossil
in_1Qn0PZG3yyC68CM0iOHGsGOl I think
so it should be in the april invoice.
The meter event before that one should be interesting. I would have expected it in the march invoice.
near reef
Ah, I should have approached this differently 😅
I am seeing notes that there are rough edges around using Meter Events and Test Clocks together. Reading more about that now.
Hm, but you are using the v1 endpoints.
If I'm understanding correctly, it looks like it takes time for events to aggregate possibly, and that if you advance the test clock before that happens they can be dropped.
If you let the scenario sit for a while after sending the meter event before advancing the test clock, does the usage eventually show up as expected?
arctic fossil
Hm, but you are using the v1 endpoints.
the go lib use it by default.
arctic fossil
If I'm understanding correctly, it looks like it takes time for events to aggreg...
This might be the case because, I have this inconsistency. Would it make any difference to use the v2 endpoints?
How long does it take to settle the aggregation?
near reef
Maybe, but my suspicion is that v2 may make it worse. I'm not sure, unfortunately, but I wouldn't think too long, maybe a minute or two?
arctic fossil
😅
ok
Ok, I will test it with a timeout of some minutes and get back here if this doesn't work. Thank you for your support sir! :)
near reef
Any time! (Sorry it's a lot of guessing this time around 😅 )