#nukesforbreakfast_unexpected

1 messages ¡ Page 1 of 1 (latest)

mental furnaceBOT
#

👋 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/1219374390320562298

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

severe pierBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

copper sedge
#

I have tested the behavior in the test env, and I'm seeing behavior I did not expect as per the notes above.

severe pierBOT
half kraken
copper sedge
#

let me attempt this

#

what's the correct way to update the draft invoice with the new service client API?

half kraken
#

Good question, that is with the PHP library right?

#

Actually I think a few of our libraries just got updates like that. which of them are you using?

copper sedge
#

Python sorry

#

looks like it's this: client.invoices.update(third_revision.id, params={"due_date": revised_invoice.due_date})

half kraken
#

That looks correct to me, let me know if you get an error.

copper sedge
#

it seems that update after creating the draft worked. However, there's an edge case that is not working:

#

I advanced the test clock so the invoice became past due, test clock ID clock_1OvmAYB7kbjcJ8QqMHLBxErh

#

I then tried to create a third revision with a due_date equal to the due date of the second revision:

# 
client.invoices.update(third_revision.id, params={"due_date": second_revision.due_date})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rccausey/.cache/pypoetry/virtualenvs/signature-check-JUY3r3PR-py3.11/lib/python3.11/site-packages/stripe/_invoice_service.py", line 1983, in update
    self._request(
  File "/home/rccausey/.cache/pypoetry/virtualenvs/signature-check-JUY3r3PR-py3.11/lib/python3.11/site-packages/stripe/_stripe_service.py", line 26, in _request
    return self._requestor.request(
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rccausey/.cache/pypoetry/virtualenvs/signature-check-JUY3r3PR-py3.11/lib/python3.11/site-packages/stripe/_api_requestor.py", line 176, in request
    resp = requestor._interpret_response(rbody, rcode, rheaders)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rccausey/.cache/pypoetry/virtualenvs/signature-check-JUY3r3PR-py3.11/lib/python3.11/site-packages/stripe/_api_requestor.py", line 569, in _interpret_response
    self.handle_error_response(rbody, rcode, resp.data, rheaders)
  File "/home/rccausey/.cache/pypoetry/virtualenvs/signature-check-JUY3r3PR-py3.11/lib/python3.11/site-packages/stripe/_api_requestor.py", line 242, in handle_error_response
    raise err
stripe._error.InvalidRequestError: Request req_WTJ4SZT2GiDweZ: The parameter `due_date` expects a unix timestamp representing a date and time in the future. You specified the value `1714592880` but have a Test Clock currently frozen to `1714765680`.
#

is this not possible? I have a use case where charges on an invoice can get appealed to the Connected account, and the review process can take 4-6 weeks. During this time the invoice due_date would likely come to pass. If the appeal succeeds, it could lead to a revised invoice needing to be created.

half kraken
#

Unfortunately not. I can put in a feature request about handling due dates in the past but for now that is a restriction on how our invoices work

copper sedge
#

ok

#

that would be helpful.

#

I think the restriction makes sense for invoices that are not created as a revision

#

but for revisions, ideally it should keep the same due date.

#

is it expected that the due date doesn't copy over on the revision?

half kraken
#

I am not seeing explicit confirmation on this either way in our docs. Will ask my colleagues and get back to you

mental furnaceBOT