Actions: Add workflow for marking stale questions

[aeisenberg]

This PR adds a workflow for marking and closing issues as stale. Issues must be labeled as question. PRs are never marked as stale.

[aeisenberg]

I've set the debug-only flag to true, but looks like debug info is not being displayed. I think we need to set ACTIONS_STEP_DEBUG as a repo secret. Can someone with access set this secret and re-run the workflow?

[adityasharad]

Looks reasonable, a few suggestions.

[adityasharad]

I think we can drop the pull_request trigger and just do testing via workflow_dispatch on branches.

Suggested change

	pull_request:
	paths:
	- codeql/.github/workflows/close-stale.yml

[aeisenberg]

path is incorrect also. I need to have this run once before it appears as an option for workflow_dispatch. I'll remove it later.

[adityasharad]

Added ACTIONS_STEP_DEBUG=true. Go ahead and rerun the workflow.

[aeisenberg]

Currently, the workflow will mark 120 issues as stale. I spot checked a few of them and they all do seem legitimately stale.

[aeisenberg]

I think this looks good. I see no problem running against all historic issues. Here are the issues that would have been closed. I'll make sure no other committers have an issue with this, before merging.

• LGTM doesn't remove alerts for a language when all items have been removed  #5501
• CI: Make more workflows public #5480
• Java: Modifiable.hasModifier(string) reports implicit modifiers #5472
• #5451
• Detect String Encoding type with CodeQL after String extraction #5441
• Java: Wildcard reports implicit Object as bound #5405
• Java: IntersectionType does not match multiple upper bounds of type variable #5404
• Java: IntersectionType is missing predicates and does not work correctly #5403
• Java: AnnotationElement does not extend Method #5399
• There is no parsing library for build.gradle file #5392
• Autobuilder Support for C++ with Gradle #5376
• InlineExpectationsTest documentation regarding .expected file is misleading #5343
• Autobuild does not find maven build (pom.xml) files in subdirs  #5331
• Java: Deprecate and remove Element::getDoc #5320
• Feature request: generate AST for code snippet on LGTM.com #5314
• #5298
• Query Console has no result when splitting supplementary code points #5297
• I can't dechiper error message for query. #5291
• Query Console does not show elements without toString() / Some elements have no toString() #5290
• Java: Javadoc.getCommentedElement() returns bogus MetricElement & Annotatable #5289
• Java: Package and Module do not extend Documentable #5288
• Some .qhelp files appear to be unused #5274
• Getting Dataflow graph for method #5213
• General issue - JavaScript data flow analysis #5177
• CodeQL CLI Extractor Backtraces, Missing Files #5115
• General issue - Using this taint-tracking script can only show the source node and sink node? #5104
• demo work fine on LGTM,but error on cli, INVALID_RESULT_PATTERNS #5084
• Issue regarding getting intermediate node locations in a Data Flow Graph #5079
• General issue on building the codeql databse #5054
• Java: Data Flow Tracking for Stream/Promise based data flow #4988
• How to get the RefType without import #4937
• No type information for Angular(typescript) codebase #4930
• What command line format when including a quoted string? #4910
• Query running forever #4909
• cannot search MethodAceess inside source code #4902
• getType is null for variables in typescript files #4890
• false positive results of relativePath #4883
• False positive results of Finding spurious @param tags #4870
• Java Code Scanning and Semmle Query Suites Allows for Trusting All Certificates in SSL Connection #4852
• Java Code Scanning and Semmle LGTM Query Suites Allows for Weak Crypto with BlowFish Key size < 128 #4851
• General issue #4843
• Java: Extend JAXB.qll to cover Jakarta XML Binding #4840
• Got error while analyzing a Go db #4815
• CodeQL incorrect documentation encourages vulnerable Cryptographic Java API Usage #4804
• CodeQL for Stack Overflow Snippets #4788
• Kotlin support #4699
• can codeQL analyze Broken Access Control vulnerabilities or unauthorized vulnerabilities? #4651
• Java: TaintTrackingUtil.qll ObjectInputStream.read% taint is faulty #4591
• General issue : false negative during evaluation of UseBraces #4551
• Java: queries about user-controlled URLs should be sanitized by enforcing a prefix #4530
• Error while creating local python database #4496
• LGTM fails on Android Build-tools 30 #4470
• Questions to workflow integration #4426
• Broken qhelp links #4379
• Scala Compatibility #4365
• LGTM doesn't remove language checks when all items have been removed #4284
• ERROR: Could not resolve module javascript.  #4280
• Weird(?) behavior of Expr.getType #4180
• PHPStorm extension #4168
• Suggestion: toHex method for int #4145
• CodeQL can't find the C++ API xmlFree from libxml2 #4128
• Java: Add Import.getATypeImport #4119
• General issue: Cannot upgrade database #4034
• [Java] WildcardTypeAccess.hasNoBound() returns wrong result for array bounds #4005
• Context/Path Sensitivity of Different Modules #3967
• JavaScript Webpack Vulnerability #3963
• XML in javascript hasn't been written?[QUESTION][XML] #3949
• Java: Clarify that Expr.getLocation does not include parentheses #3908
• Java: Improve "Learning CodeQL" docs #3903
• Java: JavadocText does not exist for empty block comment / javadoc lines #3827
• Java: Some JavadocTag line numbers are wrong #3826
• Java: JavadocTag does not contain multi-line JavadocText children #3825
• Java: Add predicate for getting ordered super interfaces #3818
• CodeQL GitHub Action works on upstream but not on fork #3799
• Java: Member.getQualifiedName does not use qualified name of declaring type #3711
• Taint is stuck in exception variable declaration of a catch clause: catch(Exception e) #3710
• Catch clauses should (maybe) not be enclosed by their try stmt #3709
• Statement encloses itself #3707
• Java: Modifier.getLocation() does not work #3705
• Java: Javadoc.getCommentedElement / Documentable.getJavadoc does not work for annotated elements #3698
• Java: Clarify that each line of block comment is separate JavadocText #3696
• Java: Javadoc matches regular comments #3695
• Java: Add TypeAccess predicate for finding out if access is fully qualified #3649
• Java: TypeAccess matches implicit access #3648
• Java: Class for inline javadoc tag #3647
• Java: Comparing Location leads to incorrect results #3644
• Java: Add common base class for SwitchStmt and SwitchExpr #3642
• Java: Add CharacterLiteral.getIntValue #3635
• Java: Add ArrayTypeAccess C-style predicate #3624
• Issue in labeling the correct place of the alert in sql injection queries #3623
• Java: LambdaExpr.getExprBody() parent is always ReturnStmt #3605
• LGTM is too Chatty #3493
• C extractor database error #3461
• odasa analyzeSnapshot --sarif-add-snippets option is not documented #3428
• Java: FunctionalInterface does not find all functional interfaces #3418
• Java: Add predicates for getting annotated types / TypeAccess #3417
• Uninformative error message from qltest when there are no source files #3406
• Need help for write query [cpp] #3292
• C++: Range analysis not picking up on condition because of implicit casts #3290
• General issue #3289
• Java: VariableAssign (LocalVariableDeclExpr) is not an Assignment #3266
• Using "Value::named" search for call to "os.path.join" not working #3261
• General issue - suppress warnings from codepath #3252
• Make TearDownMethod match more than JUnit 3.8 #3102
• Match JUnit 5 in TestMethod, TestClass, AssertionMethod ... #3101
• How to open rel file in a CodeQL database？ #3100
• Can vscode open the Path Explore? #3017
• I cant find the java.naming.xxx class in codeql #2954
• Build error in C#8 #2952
• General issue - py/not-named-cls should trigger for implicit class methods #2826
• #2775
• Potential false positives - cs/dereferenced-value-may-be-null - when working with C# 8 nullability feature #2774
• Python Taint Flow: False negative when taint originates in default value of function argument #2749
• Unable to control which repos I see alerts for #2714
• CLI incompatible with dataset #2548
• Error NO_KIND_SPECIFIED #2508
• Merge conflicts on LGTM when merge conflicts don't exist in-code #2477
• Fancy scroll to anchor feature doesn't scroll to correct place. #2424
• This is _not_ a good Dispose() call :) #2337

[geoffw0]

Just scanned through the list above, looking mostly for C++ issues. They're certainly stale, most are questions, but there are a significant number of mislabeled suggestions (perhaps the correct label for these is not obvious?). Having something remind us to deal with these seems like a good idea. I would want a notification before any automatic closure (I get the impression the PR does this).

What's the minimum I'll need to do to prevent something from being closed? Will assigning it or changing labels work, or do I need to comment?

---

I've just dealt with:

• CodeQL can't find the C++ API xmlFree from libxml2 #4128 "CodeQL can't find the C++ API xmlFree from libxml2"
  • two follow up questions were asked but not answered. Closed.
• Need help for write query [cpp] #3292 "Need help for write query [cpp]"
  • I replied but the thread stopped there. Bit surprising considering how much effort the author had put into writing it up, but I'm guessing the problem was solved or forgotten long ago. Closed.
• C++: Range analysis not picking up on condition because of implicit casts #3290 "C++: Range analysis not picking up on condition because of implicit casts"
  • this was answered I think to the satisfaction of all. Closed.
• can codeQL analyze Broken Access Control vulnerabilities or unauthorized vulnerabilities? #4651 "can codeQL analyze Broken Access Control vulnerabilities or unauthorized vulnerabilities?"
  • I asked some questions but was not answered. We still don't know what the question was about. Closed.
• Some .qhelp files appear to be unused #5274 "Some .qhelp files appear to be unused"
  • a suggestion not a question; added to my backlog
• I can't dechiper error message for query. #5291 "I can't dechiper error message for query."
  • unanswered question, I'm following up on it now.

Update: and the CPP team has decided:

• https://github.com/github/codeql/issues/2775 "C++ IR: Misleading toString on PhiInstructions"
  • this has been relabeled from "question" to "enhancement". I hope that will prevent it from being closed.
• Weird(?) behavior of Expr.getType #4180 "Weird(?) behavior of Expr.getType"
  • this should stay open because the problem remains and is referenced in two 'short term' extractor issues. I've also relabeled it from "question" to "enhancement".
• C extractor database error #3461 "C extractor database error"
  • this has been closed.
• Error NO_KIND_SPECIFIED #2508 "Error NO_KIND_SPECIFIED"
  • this has been answered and closed.

---

These look worthy of our attention, any volunteers?

• Broken qhelp links #4379 "Broken qhelp links"
• https://github.com/github/codeql/issues/5298 "Improve string predicates documentation"

[aeisenberg]

Thanks for going through the open issues. Now that we have the first responder rotation, I expect that we won't have any more of these mislabeled issues.

I would want a notification before any automatic closure (I get the impression the PR does this).

Yes. There are two steps. The first is marking the issue as stale, which adds the label as well as a comment. The second step is to close the issue 7 days later.

What's the minimum I'll need to do to prevent something from being closed? Will assigning it or changing labels work, or do I need to comment?

Either comment or remove the the stale label.

[geoffw0]

Sounds great. 👍

[Marcono1234]

What was the intention of adding this workflow? Was it in general the too high volume of issues, or was it that there were too many issues on which the reporter never responded back?
If the intention was to close issues without reporter response, then this workflow is in my opinion too destructive. A similar situation occurred in https://github.com/actions/stale and https://github.com/actions/starter-workflows, though they let it run for pull requests, and to be fair apparently had / have a bigger spam problem than this repository. In the end the bot closed a bunch of legit issues, where the maintainers never even responded in the first place, or where the reporter was waiting for the response of a maintainer.
And it looks like the same is happening here now, of the 15 issues currently labeled as stale, #5441 seems to be the only one where you are actually waiting for the response of the reporter. In all other cases there has either been no interaction at all from you maintainers, or you told them that the topic will be discussed internally. I am not trying to blame you for not interacting with the issues, especially since I may be one of the major creators of issues, though on the other hand I am not very keen on having to comment every 14 - 21 days on my issues just to keep them open. And also there are good issues / feature requests (for which I am not the author) which would be closed as well.

If your intention is really only to resolve issues without reponse from the reporter, maybe it would be better to introduce an awaiting-response label or similar which you add after expecting a response from the reporter, and then only have the bot run for issues with this label; possibly also with a bot removing the label automatically if there has been any non-bot activity.

[aeisenberg]

Thanks for asking about this change. We've had a first responder rotation for the past couple of months. Each week one developer on our team becomes the point-person for answering questions (or forwarding to the proper team). The goal with this change is to make it clear what issues are currently unanswered or awaiting response.

Though, going through some more of the stale issues now, I see that some of them are incorrectly labeled as questions. This stale process only runs for questions (not bugs or enhancements). Part of the first-responder's job is to properly triage these new issues. Now that we have this automated process we need to be more precise about questions (relabeling and forwarding as appropriate).

Perhaps, as you suggest, we should be adding an awaiting-response label and running the stale process off of that. We keep track of this internally, but it's not visible to the public.

[aschackmull]

@aeisenberg There are a number of issues (a bunch of which was opened by @Marcono1234) that I'd like to keep around without having to interact with them every 14-21 days just to keep them open. A bunch of these are backlogged in the Java team and we haven't yet had the capacity to triage them, so we can't really say whether they are best labelled as bugs or enhancements (or indeed whether some of them might be closable as wont-fix). How do you suggest we best keep them around? Simply remove the question label? (Leaving them perhaps with no labels at all).

[leonard84]

If you are using such an workflow, then you should improve the available templates, e.g., introduce a bug report template and so on. Because right now, everything that is not a false positive or vulnerability gets labeled as question, even if it is a bug report.

Perhaps, as you suggest, we should be adding an awaiting-response label and running the stale process off of that.

Sound like a good idea.

[aeisenberg]

See here #5689. Only apply staleness to issues awaiting-repsonse.