#pollux

1 messages Β· Page 1 of 1 (latest)

maiden vergeBOT
hollow pier
#

Hello πŸ‘‹
Let's chat here

ashen slate
#

okay sure!

#

@hollow pier this is clearly a timestamp issue, I suppose Im doing the timestamps wrong

#

what should the timestamp be If I set the clock advance to 12:33, should I set it as 12:32 or after 12:33 ? to get billed on the same month

#

i did 12:32 and get this error message

#

Cannot create the usage record with timestamp 1724761979 because timestamps must not be in the future. Expected a timestamp less than or equal to 1722083700.

hollow pier
#

Can you share the request ID?
Also I remember sharing a summary in the previous thread. I can't seem to locate it for some reason

Can you copy paste the summary here if you're seeing the previous thread?

ashen slate
#

here is the link [#1113189526899269762 message](/guild/841573134531821608/channel/1113189526899269762/)

hollow pier
#

To summarize ( timestamps are in UTC)

You have a test clock subscription with ID sub_1NDY8uGuTUZZ6Si6Wk0o7q3J

Currently Subscription's
period_start: 2024-04-27 12:33:00 +0000
period_end: 2024-05-27 12:33:00 +0000

When you sent a request to report the usage
https://dashboard.stripe.com/test/logs/req_KUFZDNCQd6xsse

You reported usage for 2024-04-26 12:33:00 timestamp
That not working is expected as you can't report usage for previous period after a new cycle has started (except for the first 5 minutes of the new cycle)
What time did you have on the billing clock when you reported the usage?

#

If the clock has advanced to 12:33 then you should set the timestamp less than 1722083700 but greater than 1724761979

ashen slate
#

yeah, so this is only a problem if it a test clock right?
so if it in production I should be just doing
const timestamp = parseInt(Date.now() / 1000);

#

not current period start or end

hollow pier
#

I think you were getting the error because you had test clock set at 12:32 and were reporting the usage for 12:32:59

#

the same condition applies in production too

ashen slate
#

yeah, right now I got another error, I added 1 second to current period start and looks like the usage reporting didnt go through
Cannot create the usage record with this timestamp because timestamps must be after the subscription's last invoice period (or current period start time).

#

advanced to 12:33 exact

hollow pier
#

Can you share the request ID?

ashen slate
#

req_KD1UvFLo9pm00Y?t=1685542228

#

req_KD1UvFLo9pm00Y

#

ohh looks like i calculated timestamp wrong

#

that is not a unix time stamp

#

let me try that agin

hollow pier
#

πŸ‘

maiden vergeBOT
ashen slate
#

Nope, added 1 minute to current period start, and the usage got added to next billing cycle

#

im so lost now

#

sub_1NDY8uGuTUZZ6Si6Wk0o7q3J

#

okay so what time stamp should I be adding? what time should I set in advance clock? @hollow pier

#

The timestamp has to be within the current billing period, otherwise the call fails.

#

what does current billing period mean here?

#

the timestamp cant be before the invoice got created!
adding current period start/end, bills to the next billing cycle

#

adding current period start + 1 minute => next billing cycle

#

now ill try adding current period start - 1 minute?

winged badger
#

Hello, Hanzo had to step out but I'm catching up and will get back to you in a bit

ashen slate
#

sure

winged badger
#

Current billing period means the time between current_period_start and current_period_end on the subscription object

ashen slate
#

okay, so I should subtract right? from the current period start?

winged badger
#

That error message makes it seem like it should be after

ashen slate
#

ohh that error message, I had the wrong timestamp

#

i calculated it wront, it not even a timestamp

ashen slate
#

docs says

#
If aggregate_usage is set to sum on the price, there’s an additional five minutes after the end of a billing period when you can report usage (this is to accommodate for clock drift). For all other aggregate_usage values, the timestamp has to be within the billing period.
#

so it should be before current period start for sure

#

ohh wait

#

so it does mean after ? within the 5 minute mark

#

so how do I make this work with test clock? and what time stamp should I be adding

#

I think Im doing this exactly wrong

#

I added timestamp as current_period_start with clock advance to 12:33 and the usage got remported at 27-Nov-2024, 12:33 pm 80000

#

still this was added to the next billing date, not the current billing invoice

#

is there some setting options that I didnt select?

winged badger
#

It should apply automatically as far as I know. Not sure why this isn't working as expected. Checking in to your subscription again

ashen slate
#

i did another clock advancement, with 1 minute added extra to current period start for timestamp (there is 5 min gap)

#

still same thing

#

got billid to the next billing cycle

#

usage 27-Dec-2024, 12:34 pm 80000

winged badger
#

And I assume you have already tried setting the timestamp in the past during the period of the previous invoice?

ashen slate
#

so should I subtract 1 minute to current period end of last billing cycle?

#

what time should I set in the test clock?

#

I did this, got error message

#

Cannot create the usage record with timestamp 1740659520 because timestamps must not be in the future. Expected a timestamp less than or equal to 1737981180.

winged badger
#

Correct. I would say set the test clock to one minute after the phase ends and then record usage for one minute before the phase ended. So if the subscription cycles at 12:00 set the clock to 12:01 and report usage for 11:59

ashen slate
#

@winged badger got the same error Cannot create the usage record with timestamp 1743078720 because timestamps must not be in the future. Expected a timestamp less than or equal to 1740659640.

#

req_eZxCH2ibth5ODp

winged badger
#

1743078720 is one month ahead of 1740659640

ashen slate
#

hmm..... tyring that again

#

yeah!

winged badger
#

Yeah if you try with a timestamp that is a bit before the current_period_start (which is now 1740659580), you should see something different

#

Hopefully this working properly 🀞

ashen slate
#

@winged badger did not work

#

sub_1NDY8uGuTUZZ6Si6Wk0o7q3J

#

see usage! its 12:32

winged badger
#

Gotcha. So usage got reported again but still on the next invoice?

ashen slate
#

this is what Im sending

{
  subItemId: 'si_NzXD8eaLB1eixZ',
  usageQuantity: 20000,
  timestamp: 1745757120,
  idempotencyKey: 'FF3A8INqwc3M946oVV6kz'
}```
ashen slate
#

timestamp: dayjs.unix(currentPeriodStart).subtract(1, 'minute').unix(),
currentPeriodStart is from even.stubscirptions

winged badger
#

Thanks, still looking in to this. I will pull in a colleague that may know more. I have been having trouble finding more info on if there is something else that is supposed to be done here

ashen slate
#

okay sure

#

πŸ™‚

winged badger
#

I actually see that the draft invoice has an interval that ends on 1745756880, can you try logging usage that is before that timestamp?

ashen slate
#

sure trying

#

@winged badger threw an error

#

req_aR8ItHTnnLaIpT

#

tiemstamp was 1748348820

#

12:27

winged badger
#

Thank you. Apologies for all the trouble here, discussing this with my colleagues and will get back to you with what I can find

ashen slate
#

sure

#

is ther some settings I need to set?

#

how do I check if price is set to sum?

winged badger
ashen slate
#

should it not be sum? prod_NzTuuApx33OgzK

winged badger
#

It looks like your price does have this set to sum. I checked that earlier to see

#

It should be sum as far as I know. The doc specifically says it should be sum

ashen slate
#

wait i created the price through the UI

#

and selected sum

#
Charge for metered usage by

Sum of usage values during period
maiden vergeBOT
ashen slate
#

its is actually set to sum, I just checked price_1NDUwYGuTUZZ6Si6iT5OjXG7

#

aggregate_usage = sum

ashen slate
#

@amber lark I have no idea what to do now

#

😦

winged badger
#

We're still checking in to this on our side and will update you

ashen slate
#

okay sure πŸ™‚

#

I thought you left coz dingbot added a new mod

#

Ohhhhhh waiiiiit

#

I had the wrong product Id!

#

let me try the whole thing again!!!!!

#

that would have been a problem right? @winged badger

#

its all the same tho

winged badger
#

I thought I checked the price that was actually on your subscription. My colleague is seeing this same issue with a product that I think is properly set up

ashen slate
#

i just checked, 1 min before and after from curretn period start

winged badger
#

Yep, we're seeing the same thing that you are at the moment.

ashen slate
#

okay great! I can release my breath now! was so frustrated for a while

winged badger
#

Glad this is a bit of a release at least. I think we need to talk to the engineering team behind this functionality to get better clarity on what is happening. Can you write an email to us on this page and then DM me your email? I will be able to pick up the email and get back to you through there https://support.stripe.com/?contact=true

ashen slate
#

of course

winged badger
#

The email doesn't need to be too in depth. I would say you are trying to test reporting usage in the five minutes after a subscription has cycled, include your subscription ID, and mention that you were talking to Pompey on Discord

ashen slate
#

okay

winged badger
#

I can fill in the rest of the details internally once I grab your message

ashen slate
#

okay sending email now

winged badger
#

Sounds good, just turned on my DMs, if you can send me your address we should be good to go

ashen slate
winged badger
#

Thank you. Not seeing the email yet but will grab it when I do

ashen slate
#

Just sent it now

#

ohh i didnt include my subscription id omg!

#

do I need to send it again?

#

@winged badger

winged badger
#

I see it now!

#

Thank you

#

Grabbed it. Will get back to you through that email