DISCLAIMER: I know this PR is big :(, but I felt it was necessary already when I tried to add query_flag for declare and I noticed that I probably had to duplicate methods in the current design (from send existing integration), and the NRE API UX felt bad. I feel that letting this refactor for later would have made it harder.
Fixes #308 #242
Besides adding query_flag for declare
and deploy_contract
, this PR proposes a refactor of the internal transaction flow of Nile, improving the NRE interfaces, and making it easier to add logic to transactions in one place, among other things...
Now NRE transaction execution commands always (must) return a transaction status, containing the tx_hash, the status of execution (ACCEPTED, REJECTED, etc...), and error messages in case of REJECTION, improving the UX. status
is always used even when track or debug are not set, with the difference that it doesn't hang, but return the current status.
These are some examples of what you can do with scripting now:
# script.py
async def run(nre):
accounts = await nre.get_accounts(predeployed=True)
account = accounts[0]
# get account declare wrapper
# the wrapper is for registering deployments, or declarations, those Nile specific things
# you could use the low level transaction to avoid this, and just execute the transaction
tx = await account.declare("Account", watch_mode="track")
# get the estimate fee in WEI
fee = await tx.estimate_fee()
# get the simulation trace in a dict
simulation_trace = await tx.simulate()
# execute the transaction
# you will get the tx_status even if you pass pass watch_mode=None
# in this case the transaction won't hang, and the status will be PENDING
# in a testnet (probably, could be REJECTED)
tx_status, _ = await tx.execute()
# print ACEPTED_IN_L2
print(tx_status.status)
# more info in tx_status, always available after the execution
print(tx_status.tx_hash, tx_status.error_message)
IMPORTANT: There are a lot of tests to either add, refactor or remove, then I will wait for approval of the logic before starting adding coverage. I tested the features manually before submitting them.
NOTE: The only command I haven't refactored is the deploy of the account itself, because deploy_account is not using execute_call, but calling the gateway directly. I know this is because deploy_account in starknet_cli requires a straknet account, and is not open to integrations @martriay. I would need to work in a work around for this, but I didn't want to delay this PR more. That's the only command that is not going through the new flow.
Every feedback is appreciated, I know there should be a lot of details, but I hope the idea would help us.