fix: fuels dev hangs after compilation errors
#3504
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
This PR is published in NPM with version 0.0.0-pr-3504-20250102160454 |
Dhaiwat10
requested review from
digorithm,
arboleya,
Torres-ssf,
danielbate,
nedsalk and
petertonysmith94
as code owners
Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk>
Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk>
Co-authored-by: Peter Smith <peter@blueoceancomputing.co.uk>
| error(err.message); | ||
| if (config) { | ||
| await config.onFailure?.(config, <Error>err); |
There was a problem hiding this comment.
It was always sync because onFailure returns void. ref
We could change the signature to be Promise<void> | void in some other PR - it comes in handy to be able to pass async callbacks.
There was a problem hiding this comment.
Got it. I think we could then fix the return type (still in this PR) and keep it async because the user may have an async tear-down routine for these failure scenarios, and if we don't wait, things may be left dirty.
If we leave types aside for one second, we'd be doing something similar to what we did with the test utilities for asserting Fuel errors, although this case is much less convoluted. By considering it could always be async and always awaiting for it, we cover both cases.
There was a problem hiding this comment.
I have reverted withConfigErrorHandler to be async again in 7c333c9, as well as all of the other related changes like this await, and have created #3582 because all our event listeners are synchronous. I have included this onFailure listener there as well. I think it's better to cover it all in one PR for that issue. Sounds good?
|
Coverage Report:
Changed Files:
|
fuels devhangs on generating types #1886Release notes
In this release, we:
fuels devwould hang after a Sway compilation errorSummary
This PR fixes the issue where
fuels devwould hang after a Sway compilation error. Thebuildprocess was failing and the failure was caught, but therejectcallback that is called on failure was being called with an error code1, which can't be rethrown later once thereject's error is caught in atry/catch- it has to be anErrorobject. After changing it to anError(forc exited with exit code ${code}), I realized that the error handlers present in thosetry/catches weren't re-throwing the caught error. After adding a re-throw in them, I found out that the error was further being swallowed in thebin.tsfile. The bug was fixed upon changing that.Checklist