Skip to content

Create rule S7521: Coroutine objects should be awaited #5105

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 2 commits into
base: master
Choose a base branch
from

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Jun 3, 2025

You can preview this rule here (updated a few minutes after each push).

Review

A dedicated reviewer checked the rule description successfully for:

  • logical errors and incorrect information
  • information gaps and missing content
  • text style and tone
  • PR summary and labels follow the guidelines

(visible only on this page)

=== Message
Await this coroutine or store it in a variable to be awaited later.
Copy link
Contributor

Choose a reason for hiding this comment

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

With this approach I actually think we could implement it in sonar-python without DBD...
Finding the absence of await on the stored object would actually be difficult, even with DBD.
Probably worth discussing with someone from DBD before any implementation though, and depending on that, we can adapt the message.

Copy link
Contributor

Choose a reason for hiding this comment

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

With this approach, I agree.
The behavior and limitations should be clearly defined in the tests.

In the long term, I really think DBD or a taint analysis engine are the more robust implementation

Copy link
Contributor

Choose a reason for hiding this comment

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

That makes sense!

@guillaume-dequenne guillaume-dequenne changed the title Create rule S7521 Create rule S7521: Coroutine objects should be awaited Jun 3, 2025
Copy link
Contributor

@ghislainpiot ghislainpiot left a comment

Choose a reason for hiding this comment

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

I left some small comments but LGTM!


== How to fix it

Always use the `await` keyword when calling a coroutine function or any other awaitable object (like a `Task` or `Future`). Alternatively, you can schedule the coroutine to run using methods like `asyncio.create_task()`, but be sure to save and await the resulting task.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the recommendation should be broader and use keywords like TaskGroup or Nursery to help people look for the correct replacements

Copy link
Contributor

Choose a reason for hiding this comment

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

I made a slight change in the recommendation. That said, I think the rule is a bit more generic than the others we have created so far, and probably targets someone who simply forgot to add the await keyword. I feel that by referencing Nursery, I'm now tempted to have a "How to fix in Trio" section which may not be super relevant here.
Hopefully we hit a middle ground with the new wording.

(visible only on this page)

=== Message
Await this coroutine or store it in a variable to be awaited later.
Copy link
Contributor

Choose a reason for hiding this comment

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

With this approach, I agree.
The behavior and limitations should be clearly defined in the tests.

In the long term, I really think DBD or a taint analysis engine are the more robust implementation

},
"tags": [
"async",
"asyncio",
Copy link
Contributor

Choose a reason for hiding this comment

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

We might as well add the two other libraries, since it it not specific to any of them

@ghislainpiot ghislainpiot marked this pull request as ready for review June 4, 2025 09:24
Copy link

sonarqube-next bot commented Jun 4, 2025

Quality Gate passed Quality Gate passed for 'rspec-tools'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube

Copy link

sonarqube-next bot commented Jun 4, 2025

Quality Gate passed Quality Gate passed for 'rspec-frontend'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube

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

Successfully merging this pull request may close these issues.

2 participants