The comment mentions OOMs under--check-diff-informed but doesn't provide sufficient context about the issue or potential solutions. Consider adding more details about the specific test case causing the problem and any planned follow-up actions.

I don't think we should exclude sources here, as the path is fully reported.

You mean path-problems always report the location of source and sink? That seems to contradict the example ofWebviewDebuggingEnabled.ql/WebviewDebuggingEnabledQuery.qll mentioned in the incremental codeql docs.

It does seem to contradict that example, yes. I'm not completely sure here, but both ends of the pathare a part of the result tuple. From the QL point of view, it's a bit arbitrary whether the second end-point is included in the message or not - a lot of queries do this, but from the query writers perspective it's perhaps a bit of a coin-toss, since the path includes both end-points regardless. Now if this coin-toss decision affects whether or not a result is included in a PR, then of course it shouldn't be made arbitrarily, and if that's the case then perhaps we should institute a rule (e.g. in ql-for-ql) to always include the second end-point in the message.

Now, as mentioned, I'm unsure about the filtering semantics of the downstream consumption in PRs, but considering the two possible cases then either these kind of results aren't filtered in which case we shouldn't exclude sources here, or theyare filtered in which case I think we alsoshouldn't filter here, since then I'd argue we'd want to modify the query to include the source in the message to prevent the filtering.

We should move this conversation to slack and figure it out.

According to thedocumentation we only want to report alerts on locations that are pertaining to either the primary location (location of the first element in the select) or an alert pertaining to a related location - locations for elements used in placeholders@.
For theExecTaintedEvironment the "source" is the second column (so not a primary or related location), so it should be fine to set thegetASelectedSourceLocation tonone(). Note that this doesn't mean that we will disregard "all" sources as a part of the flow path computation as a source is stillrelevant if there is a relevant sink.

Ah ok, you are questioning the design (saw the thread in slack).

Same. The query reports the full path, so we shouldn't exclude sinks like this.