Is there any particular reason why only local flow is used (instead of making a data flow configuration and using global flow)?

I don't know if there's any reason. I simply migrated the query as is from the private repo.

I just tried the below:

private module FlowConfig implements DataFlow::ConfigSig {
  predicate isSource(DataFlow::Node source) { source.asExpr().(IntegerLiteral).getIntValue() = 0 }

  predicate isSink(DataFlow::Node sink) { exists(Sink s | s.getArgument(0) = sink.asExpr()) }
}

private module Flow = DataFlow::Global<FlowConfig>;

from DataFlow::Node sinkNode, Sink s
where Flow::flow(_, sinkNode) and s.getArgument(0) = sinkNode.asExpr()
select s, "ScheduledThreadPoolExecutor.corePoolSize is set to have 0 threads."

It resulted in some new findings, for example this, which is a FP.

• Where is the source of the FP located?
• Are you categorising it as an FP due to the threads > 0 check?

I haven't checked the source, only saw the threads > 0 check.

For some reason the global dataflow doesn't properly use the guard check threads > 0 in this case. Not sure why that happens (it works fine in a local flow example). Let's keep it as it is then (as you also mentioned offline - the most relevant usecase is probably immediate initialisation with 0 or something that can be picked up by local flow).

Maybe put some hyphens in the id for readability?

Changing the ID would be a breaking change for customers already using this query. Do you think improving the readability of the ID is worth doing?