-
Notifications
You must be signed in to change notification settings - Fork 316
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
feature: add auto restore functionality for contract client #974
Conversation
A couple of interesting things I found:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is gonna be so great! Various notes on the interface below. Really curious to hear from @Shaptic on your questions above.
updateTimeout: false | ||
})) | ||
.then((result) => { | ||
expect(result.getTransactionResponse.status).to.equal(rpc.Api.GetTransactionStatus.SUCCESS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you find this test satisfying? Is there a meaningful way it can fail? Seems sorta like "if I make f(x)
always return 1
then it will return 1
".
Is there a better test we could write, that exercises real functionality? Like our e2e
tests do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, its not the most satisfying test. However, I'm not sure how to do something like the e2e tests because you can't force a restore via any parameters. It has to be done at the server level (changing the minimum TTL) which would still require you to wait x amount of time, or if you put it too low it breaks functionality. So the only way I coudl think to write a test was to mock the response. What I could do is a better pattern match for the request, I was having trouble getting it to match exactly what the request is but its possible - just would take more detailed reconstruction of the specific transaction objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah unfortunately testing restores is difficult by default at all levels of the stack. We'd have to have a custom rpc+core in the e2e tests that speeds up archiving :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which makes me wonder: maybe we can run e2e tests only in CI and use a custom quickstart image?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we discussed on the call this week, we will add the ability to modify the minimum TTL as a quickstart variable or some preset config which we can then use for an e2e test of this. For now I suppose the current test is okay?
Yeahh this has been a long-standing issue with the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll have to release this in a minor release so that I can tag v12 stable today with no changes from the RC. This'll be better for the CLI release train too, I think.
updateTimeout: false | ||
})) | ||
.then((result) => { | ||
expect(result.getTransactionResponse.status).to.equal(rpc.Api.GetTransactionStatus.SUCCESS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah unfortunately testing restores is difficult by default at all levels of the stack. We'd have to have a custom rpc+core in the e2e tests that speeds up archiving :/
updateTimeout: false | ||
})) | ||
.then((result) => { | ||
expect(result.getTransactionResponse.status).to.equal(rpc.Api.GetTransactionStatus.SUCCESS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which makes me wonder: maybe we can run e2e tests only in CI and use a custom quickstart image?
fix name Co-authored-by: Chad Ostrowski <[email protected]>
better description Co-authored-by: Chad Ostrowski <[email protected]>
Better auto restore failure message. Co-authored-by: Chad Ostrowski <[email protected]>
523a526
to
ae4db84
Compare
All comments are addressed except regarding the test. I think we can use this test for now until we have a way of using a quickstart image with a short minimum TTL that would be suitable for this type of e2e test. Changelog has been added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work here, thanks @BlaineHeffron!
@BlaineHeffron if you can resolve the conflicts I can merge this asap! |
@BlaineHeffron is out today! I resolved the conflicts but didn't have permission to push to Blaine's fork, so I made a new PR, if you want to merge that one and close this one, @Shaptic! #991 |
Adds the ability to set
restore
to true in contract method invocation options. This will utilize the signTransaction method to sign a restoreFootprint operation when found that it is needed during a simulation.