github-security-report 0.14.1__tar.gz → 0.14.2__tar.gz

{github_security_report-0.14.1 → github_security_report-0.14.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: github-security-report
-Version: 0.14.1
+Version: 0.14.2
 Summary: Security and quality reporting across GitHub organisations
 Project-URL: Homepage, https://github.com/lfreleng-actions/github-security-report-action
 Project-URL: Repository, https://github.com/lfreleng-actions/github-security-report-action
@@ -789,10 +789,15 @@ pull request that cannot progress until somebody responds. The count also feeds
 the row ranking, so a backlog awaiting review outranks an untouched one of the
 same size.
 
-The scan reads up to **20 review threads per pull request**, which is the single
-most expensive part of the prefetch (see the cost figures above). Where a pull
-request carries more threads than that and none of the collected ones qualifies,
-the pull request is treated as **indeterminate** rather than clear — see below.
+The scan reads the **newest 20 review threads per pull request**, which is the
+single most expensive part of the prefetch (see the cost figures above). The
+newest end is deliberate: GitHub returns review threads oldest-first and offers
+no way to order them, so reading from the front would window the threads a
+review has already worked through — the resolved ones — and report a pull
+request still waiting on its latest round as clear. Unanswered feedback is the
+recent kind. Where a pull request carries more threads than the window and none
+of the collected ones qualifies, it is treated as **indeterminate** rather than
+clear — see below.
 
 #### Automation backlog thresholds
 

{github_security_report-0.14.1 → github_security_report-0.14.2}/README.md

@@ -745,10 +745,15 @@ pull request that cannot progress until somebody responds. The count also feeds
 the row ranking, so a backlog awaiting review outranks an untouched one of the
 same size.
 
-The scan reads up to **20 review threads per pull request**, which is the single
-most expensive part of the prefetch (see the cost figures above). Where a pull
-request carries more threads than that and none of the collected ones qualifies,
-the pull request is treated as **indeterminate** rather than clear — see below.
+The scan reads the **newest 20 review threads per pull request**, which is the
+single most expensive part of the prefetch (see the cost figures above). The
+newest end is deliberate: GitHub returns review threads oldest-first and offers
+no way to order them, so reading from the front would window the threads a
+review has already worked through — the resolved ones — and report a pull
+request still waiting on its latest round as clear. Unanswered feedback is the
+recent kind. Where a pull request carries more threads than the window and none
+of the collected ones qualifies, it is treated as **indeterminate** rather than
+clear — see below.
 
 #### Automation backlog thresholds
 

{github_security_report-0.14.1 → github_security_report-0.14.2}/src/github_security_report/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.14.1'
-__version_tuple__ = version_tuple = (0, 14, 1)
+__version__ = version = '0.14.2'
+__version_tuple__ = version_tuple = (0, 14, 2)
 
 __commit_id__ = commit_id = None

{github_security_report-0.14.1 → github_security_report-0.14.2}/src/github_security_report/client/copilot.py

@@ -50,6 +50,11 @@ def _copilot_unresolved(node: dict) -> bool | None:
     every thread was seen. This mirrors the rule ``mergeable`` and the check
     rollup already follow: not established is not the same as nothing to report.
 
+    The window holds the *newest* threads (see ``_REVIEW_THREAD_WINDOW``), which
+    is what makes ``True`` reachable on a long review: unanswered feedback is
+    the recent kind, so a truncated window that finds nothing is a weak reading
+    rather than the usual one.
+
     An outdated thread still counts. GitHub marks a thread outdated when the
     code beneath it changes but does not resolve it, so the feedback remains
     unanswered -- which is exactly what the column reports.

{github_security_report-0.14.1 → github_security_report-0.14.2}/src/github_security_report/client/queries.py

@@ -120,8 +120,17 @@ _ASSIGNEE_WINDOW = 10
 # without this connection and 57, 89 or 151 with a window of 5, 10 or 20. At 20
 # a 118-repository organisation costs ~755 points of the 5,000-point hourly
 # budget, which leaves room for the several organisations a scheduled run
-# covers, and 20 threads covers a realistic review cycle: this project's own
-# most-reviewed pull requests carry single-figure thread counts.
+# covers.
+#
+# The window is taken with ``last``, not ``first``, and which end it is anchored
+# to decides whether it can answer the question at all. ``reviewThreads`` is
+# ordered oldest-first and accepts no ``orderBy``, so ``first`` collects the
+# threads a review has already worked through -- exactly the ones most likely to
+# have been resolved. A pull request that has answered dozens of rounds and is
+# now waiting on the latest would fill the window with settled threads and
+# report the outstanding ones as never seen. Unresolved feedback ages into
+# resolution rather than the other way round, so the newest threads are where
+# the column's answer lives. Same node cost, opposite blind spot.
 #
 # ``totalCount`` rides along free of node cost and is what keeps the bounded
 # window honest -- a pull request carrying more threads than the window returned
@@ -173,7 +182,7 @@ fragment RepoData on Repository {{
       authorAssociation
       author {{ __typename login }}
       assignees(first: {_ASSIGNEE_WINDOW}) {{ nodes {{ login }} }}
-      reviewThreads(first: {_REVIEW_THREAD_WINDOW}) {{
+      reviewThreads(last: {_REVIEW_THREAD_WINDOW}) {{
         totalCount
         nodes {{
           isResolved