-
Notifications
You must be signed in to change notification settings - Fork 176
fix: fix floating-promises errors #2888
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
base: develop
Are you sure you want to change the base?
Conversation
@@ -218,7 +218,7 @@ const yargsInit = () => | |||
if (openPublicationRequestedBool) { | |||
|
|||
// flush session because user ask to read a publication | |||
flushSession(); | |||
await flushSession(); |
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.
flushSession
doesn't need to be async
i guess
export const flushSession = async () => { |
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.
Making it non-async feels out of scope for this particular PR.
However, it being async doesn't matter – it acts like a synchronous function since there are no continuation points (await
s) within.
Generally-speaking, non-awaited Promises are "code smell" and there should be ESLint rules to check this. Regardless of whether or not a Promise/async-function has a return value, it should be awaited unless of course the Promise itself is fed into a subsequent process that is designed to consume it. ...there is also the whole other issue of try/catch error handling on rejected Promises, function coloring and drilling error states up into the call chain (which in the case of Thorium involves Redux Saga yield'ed functions). |
Indeed. As mentioned in the PR description, the rule had been turned off (in 8cf571e, 2023, to be precise). It's now on.
There can be merit to awaiting the promise within a function instead of returning the unawaited promise (namely, more localized stack traces should the promise be rejected). |
While viewing this code, I noticed there were a handful of places where promises were left floating – for instance, in the LCP passphrase save code, the code never actually waited for the write to go through (or whether it failed), which could be problematic.
I noticed the ESlint rule for the issue had been turned off, so I turned it on and fixed the issues – either by
await
ing where possible, orvoid
ing the promises, so as to mark them "yes, we mean to ignore the return value of this promise".