-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
Action.send(); #357
Action.send(); #357
Conversation
Makes sense
Makes sense! Thanks for this info, that's helpful.
Sounds good |
} | ||
|
||
_toRaw = async () => { | ||
return await this.#rawTx; |
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.
Can we handle whether to await it or not upstream of this function somehow? Like only call _toRaw once we know the promise has resolved? Or only use this in tasit-contract-based-account
?
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 need to think about it, not sure.
- For now, we are using that function only on
tasit-contract-based-account
GnosisSafe class.
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.
- Okay. Keep me posted. My intuition tells me that move would make sense, but I haven't thought it through fully.
- Yep, I thought so. That's part of my rough reasoning for this.
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've made a change on this PR #360
On these changes, we are assuming that the Action
will expect a sync rawTx
on the constructor but the signAndSend
function stills using await
to resolve that. It isn't 100% solution, though.
Another path is to force rawTx
to be sync (removing the await
inside of the signAndSend
but that'll make GnosisSafe.executeTransaction
to be async (on the way that is written for now).
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 don't have time to think this through fully right now - feel free to go with whatever you thinks makes the most sense for now, and I'll circle back to this soon
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.
Or wait, maybe what I just said is wrong
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 guess what I'm asking is this: At a high level, what is it about GnosisSafe.executeTransaction
that prevents it from having a rawTx ready to go right away?
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 guess what I'm asking is this: At a high level, what is it about
GnosisSafe.executeTransaction
that prevents it from having a rawTx ready to go right away?
The [#prepareTransaction](https://github.com/tasitlabs/TasitSDK/blob/4111170669afb4447cb95315f45fd4ecd1fa02ec/packages/tasit-contract-based-account/src/GnosisSafe.js#L157)
.
That function has some async calls needed to create a safe
transaction (e.g.: GnosisSafeContract.nonce (L199) and GnosisSafeContract.getTransactionHash (L201)).
These async calls are nested and needed to create the transaction that we want to be executed by the GnosisSafeContract
.
My intention is to have the GnosisSafe
encapsulating all that is possible, transparent to the user.
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.
transparent to the user or opaque to the user?
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 don't know why I've used the "transparent" word. Opaque was what I've meant. Thanks
@marcelomorgado What does |
To Be Discussed |
Ah ok cool. It's often used to mean |
@marcelomorgado I don't think any of the open comment threads gate merging this. Nicely done with this PR, by the way! Any objection to merging it now? |
Let's merge! |
#tx; | ||
#txConfirmations; | ||
#timeout; | ||
#lastConfirmationTime; | ||
|
||
constructor(txPromise, provider) { | ||
constructor(rawTx, provider, signer) { |
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.
Creating a thread for that:
Maybe a better name could be used instead of rawTx (maybe rawAction?).
Sounds good
To track easily.
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.
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.
Sounds good, thanks
Issue link
#162
Auto-close the issue?
Closes #162
Types of changes
New feature (non-breaking change that adds functionality)
Breaking change (fix or feature that would cause existing functionality not to work as expected)
Notes
The
send()
function is async and the use ofawait
on the call is necessary for now (Since we are still usingwaitForOneConfirmation()
), it should be changed on the Test suite should capture how we expect the library to be used #219The way that
GnosisSafe
was coded introduced an extra complexity to theAction
object: A function that should be sync but creates an action from a sequence of async calls (See:GnosisSafe.executeTransaction()
). The solution that I've found is assuming that therawTx
param (from Action constructor) could be a promise or not.Maybe a better name could be used instead of
rawTx
(mayberawAction
?).