We call the same concept getPromised in JavaScript: https://github.com/github/codeql/blob/main/javascript/ql/src/semmle/javascript/ApiGraphs.qll#L180-L184

We call the same concept getPromised in JavaScript: https://github.com/github/codeql/blob/main/javascript/ql/src/semmle/javascript/ApiGraphs.qll#L180-L184

Yep I noted that in c4e244e. This is called Awaitables in Python (docs), so I that's what I went with. @erik-krogh are you suggesting that we should also call it getPromised for Python, to keep the API graph interface consistent? or are you just providing additional info on how things are done in JS for inspiration?

We call the same concept getPromised in JavaScript: https://github.com/github/codeql/blob/main/javascript/ql/src/semmle/javascript/ApiGraphs.qll#L180-L184

Yep I noted that in c4e244e. This is called Awaitables in Python (docs), so I that's what I went with. @erik-krogh are you suggesting that we should also call it getPromised for Python, to keep the API graph interface consistent? or are you just providing additional info on how things are done in JS for inspiration?

Purely for inspiration.
And yeah, on further thought, calling it getAwaited in Python makes more sense than getPromised.

By this I mean: what would happen if we were to silently step from the former to the latter, without adding a specifically labelled edge?

Some context from JavaScript:
We have a taint-step that does exactly that (see PromiseTaintStep in Promises.qll).
But that is only enabled for TaintTracking configurations, not for DataFlow configurations.

My knowledge of await is fairly minimal, however, so there is one thing I'm wondering: Is there any situation where the difference between foo and await foo is significant?
By this I mean: what would happen if we were to silently step from the former to the latter, without adding a specifically labelled edge?

Would this result in false positives?

I guess you're thinking about whether we it would be worth it to make things more simple, by just ignoring this?

From the top of my head I can't really give any specific examples where silently stepping from foo to await foo would cause trouble in regards to modeling libraries, but I'm stuck with a feeling that ignoring this aspect is going to be a bit too magical, and make our analysis not respect the semantics of Python... I guess that's a rather vague argument, but I feel much more inclined towards explicitly using .getAwaited() 👍

As a more objective argument against, if we need to silently step in this way, wouldn't that also mean that API::moduleImport("foo").getMember("bar").getACall() should have both foo.bar() and await foo.bar() as results? -- and therefore it's result type could no longer be DataFlow::CallCfgNode, which seems like a big loss 😱 after thinking this over, I don't think this argument makes sense 😄 since we would probably only extend getAUse() and getReturn() to account for this...

Talked this over in person with @tausbn, and we decided that doing this automatically would be a bit too magic ✨ so we're going to go with .getAwaited() 👍