Confusion around update streams w/ Canceled
payments
#4001
Replies: 1 comment 3 replies
-
Thx for the report, I replicated the bug that I still firmly believe that update streams are the way to go, as any non-trivial client application will be interested not only in the current state of operations but also changes to these and polling is typically a bad solution. The current API and caching behavior might not be optimal though. My proposal: instead of returning update streams that do a lot of work to determine the state of operations always run these internally of the client. That way we can cache intermediate states to make querying them efficient and also create light-weight update streams that can be given to the frontend (cloning them would also be much more efficient). |
Beta Was this translation helpful? Give feedback.
-
I seem to only have a problem with streams when it comes to
Canceled
payments. I have the following code:When sending a payment, I wait up to 30s before returning to the UI that it is a pending payment. When dealing with completed payments, this seems to work just fine and returns quickly when a success happens. However, when a payment gets cancelled because a gateway could not complete it, I get the following logs:
I return to home screen 5 seconds later, where payment statuses are checked again with a quick timeout (I really don't like these streams... I just want to check the current status of the payment...)
Another observation, I'm not sure what is calling it but during the 30s timer, I get a bunch of calls to this endpoint that result in a 400:
Here's some of the gateway logs:
Basically, I'm unsure how to detect that a payment is cancelled and promptly return to the UI that it failed. Any suggestion? Could there be a bug with cancelled statuses not returning from the original stream? Seems to work when I subscribe to the operation id a 2nd time after it failed.
Beta Was this translation helpful? Give feedback.
All reactions