Skip to content

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

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

akx
Copy link
Contributor

@akx akx commented Mar 19, 2025

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 awaiting where possible, or voiding the promises, so as to mark them "yes, we mean to ignore the return value of this promise".

@@ -218,7 +218,7 @@ const yargsInit = () =>
if (openPublicationRequestedBool) {

// flush session because user ask to read a publication
flushSession();
await flushSession();
Copy link
Member

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 () => {

Copy link
Contributor Author

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 (awaits) within.

@danielweck
Copy link
Member

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).

@akx akx force-pushed the floating-promises branch from 68369e6 to 923ff21 Compare March 23, 2025 16:03
@akx
Copy link
Contributor Author

akx commented Mar 23, 2025

Generally-speaking, non-awaited Promises are "code smell" and there should be ESLint rules to check this.

Indeed. As mentioned in the PR description, the rule had been turned off (in 8cf571e, 2023, to be precise). It's now on.

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 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants