Follow up an overdue upstream issue

What the check reads

The verify-stage warning examines active KnownIssues with upstream_report. It fires when schedule.recheck_after is in the past and response.status remains non-terminal. Pending, acknowledged, duplicate, fix_in_progress, no_response and an absent response can remain in scope. Fixed and wont_fix are terminal for this schedule. A record without an upstream_report is not examined.

proof audit --check known_issue_recheck_due

An illustrative case

Illustrative case: a vendor acknowledged a defect and suggested the next minor release. The scheduled date passes. An acknowledgement does not establish that a fix shipped, so the warning remains useful. Inspect the release and rerun the relevant reproducer; an unavailable environment is an inconclusive outcome, not evidence that the issue disappeared.

Resolve the finding

1. Use proof known-issue list with the recheck-due option to inspect the overdue record and its prior correspondence.
2. Perform the recheck and record still_present, fixed or inconclusive with the version and supporting observation.
3. If work continues, set the next date. Record a terminal vendor response only when it actually arrived, and close the local issue only when its own disposition is justified.

What a clear result means

Appending a recheck outcome alone does not necessarily move the schedule. Advancing the date without doing the work only hides overdue investigation. A vendor’s wont_fix response ends this follow-up trigger but can leave a live product risk requiring a separate decision.

Continue with one real issue

Known issues reviewed · Risk acceptance

Bring one finding, its requirement and the current evidence to scope a walkthrough of what your reviewer can establish and what still needs work.