Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infinite "tx draft has expired" error #862

Closed
andywer opened this issue Nov 27, 2019 · 5 comments
Closed

Infinite "tx draft has expired" error #862

andywer opened this issue Nov 27, 2019 · 5 comments
Labels
bug Something isn't working

Comments

@andywer
Copy link
Contributor

andywer commented Nov 27, 2019

As seen on one device during the launch party:

Error occured once and then appeared immediately again whenever the user tried to create a new payment. Looks as if either no new tx is created or the SubmissionProgress is stuck at the previous state.

@andywer andywer added the bug Something isn't working label Nov 27, 2019
@ebma
Copy link
Member

ebma commented Nov 28, 2019

I tested it with payments, trading and adding assets. Every time I force a 'Transaction draft has expired' error by exceeding the transaction timeout that we set on transaction creation, I have to close the submission progress dialog and get back to the form (trading, payment or add asset).
So I always have to submit again. And I looked it up, we do create a new transaction every time the user hits submit:

props.onSubmit((horizon, account) => createPaymentTx(horizon, account, formValues))
.

So it has to do something with the SubmissionProgress (?) but I was not able to reproduce this even once so... I don't know.
@andywer are you able to reproduce?

@andywer
Copy link
Contributor Author

andywer commented Dec 2, 2019

Do we actually fetch a timestamp from horizon? Otherwise maybe it could be an inacurate user device time.

@ebma
Copy link
Member

ebma commented Dec 4, 2019

Seems like you're right about the inaccurate time of the user device.
Although we fetch the timebounds from horizon before we create a new transaction, the result seems to be based on the local user time.
(I tested it on android and macOS by setting the time back by a few hours and the fetched timebounds were calculated correctly but based on that modified time.)

I found this related issue ticket which points out that there is a bug in the sdk.

@andywer
Copy link
Contributor Author

andywer commented Jan 28, 2020

@andrenarchy is on it. I guess it will be fixed with the next horizon update.

(The actual fix is adding an access-control-expose-headers header to the response)

@andywer
Copy link
Contributor Author

andywer commented Mar 3, 2020

Should be fixed with the upcoming v0.24.0. Horizon servers are sending the correct headers now and Solar will use the latest Stellar SDK containing a fix that will make the feature actually work.

@andywer andywer closed this as completed Mar 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants