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.

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

Made sure that more of the async usages are awaited #4574

Merged
merged 3 commits into from
Mar 15, 2024

Conversation

CommanderStorm
Copy link
Collaborator

⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

  • I have read and understand the pull request rules

Description

This PR makes more of our async usages awaited and fixes the annotations for those async functions where we are missing them.
The former was mostly found via WebStorm's inellisense, while the latter were found by looking at every async file.

Type of change

Please delete any options that are not relevant.

  • Other

Checklist

  • My code follows the style guidelines of this project
  • I ran ESLint and other linters for modified files
  • I have performed a self-review of my own code and tested it
  • I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
  • My changes generates no new warnings

Screenshots (if any)

Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.

Copy link
Collaborator

@chakflying chakflying left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good finds. I think there are cases where technically we don't have to wait for something to be done, but we should just do it for consistency.

@CommanderStorm CommanderStorm merged commit 0e3b3a9 into louislam:master Mar 15, 2024
5 checks passed
@CommanderStorm CommanderStorm deleted the better-race-safety branch March 15, 2024 14:03
Comment on lines +1622 to +1628
await sendInfo(socket);
await server.sendMaintenanceList(socket);
await sendNotificationList(socket);
await sendProxyList(socket);
await sendDockerHostList(socket);
await sendAPIKeyList(socket);
await sendRemoteBrowserList(socket);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion, using await or not is depending on the design. The need of blocking and non-blocking.

Here, most of them are actually intended not to use await, because they are independent. And for MariaDB, they can query at the same time without doing one by one.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. But also, the final user experience will still depend on many factors. For example, if we are IO-bound on the server-side, there is no benefit to blasting off the responses all at once, and awaiting makes the application behavior more predictable. Having to sleep(500) seems crude in comparison.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe something like Promise.all() would be a good compromise?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in this case Promise.allSettled() might be better, but yes (am going to propose another PR incl. remmoving the sleep)

I was afraid of running into weird unreproducible race conditions, but in this case this is likely ok ^^

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

Successfully merging this pull request may close these issues.

3 participants