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.

Sign up for GitHub

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

Jump to bottom

Make deployContract Method a Non-Blocking Call #2561

Open
Torres-ssf opened this issue Jun 20, 2024 · 2 comments · May be fixed by #2597
Open

Make deployContract Method a Non-Blocking Call #2561

Torres-ssf opened this issue Jun 20, 2024 · 2 comments · May be fixed by #2597
Assignees
@Torres-ssf
Labels
feat Issue is a feature p0 High priority
Milestone
0.x mainnet

Comments

@Torres-ssf
Copy link
Contributor

The deployContract method in the ContractFactory currently submits the transaction and waits for it to be processed. This synchronous approach can lead to significant delays, as transaction processing times in a blockchain environment often take several seconds.

Having this method always act as a blocking call is impractical for real-world blockchain environments as it forces developers to wait for transaction completion before proceeding with other tasks.

The deployContract method should only wait for the TX to be processed if the user explicitly chooses to do it. This non-blocking approach should be the default behavior, as blocking the UI is not what users usually desire.

similar to #2492
@Torres-ssf Torres-ssf added feat Issue is a feature p0 High priority labels Jun 20, 2024
@Torres-ssf Torres-ssf added this to the 0.x mainnet milestone Jun 20, 2024
@Torres-ssf Torres-ssf self-assigned this Jun 20, 2024
@Torres-ssf Torres-ssf added bug Issue is a bug and removed feat Issue is a feature labels Jun 20, 2024
@arboleya
Copy link
Member

Are we talking about adding the awaitExecution flag as a new parameter?

fuels-ts/packages/contract/src/contract-factory.ts

Line 164 in dc17b9c

awaitExecution: true,

@Torres-ssf
Copy link
Contributor Author

@arboleya Yes, we will also need to change the method's response type.

Currently, it returns an instance of the Contract class, ready to be used. This is only possible because the method waits for the transaction to be processed.

The ideal approach would be to have the deployContract method simply submit the transaction and return something that can be used to fetch the transaction, such as its ID or an instance of TransactionResponse. This way, dApp applications wouldn't get blocked when submitting the TX, and they would receive the transaction ID as a response, making it possible to attach hooks to fetch its status.

@arboleya arboleya added feat Issue is a feature p0 High priority and removed p0 High priority bug Issue is a bug labels Jun 20, 2024
@Torres-ssf Torres-ssf linked a pull request Jun 24, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Torres-ssf Torres-ssf

Labels
feat Issue is a feature p0 High priority
Projects
None yet
Milestone
0.x mainnet
Development

Successfully merging a pull request may close this issue.

feat!: add a non-blocking call for deploy contract FuelLabs/fuels-ts
2 participants
@arboleya @Torres-ssf