Retest outcomes

Before reading an outcome

Use this page after a fix task has an approved connected change or customer-applied evidence and a retest run has been requested. A retest outcome is the evidence-backed result that says whether the original issue fingerprint is still observed. Do not mark a fix resolved from a status label alone. The outcome should connect the fix task, retest scan run, original issue fingerprint and remaining evidence.

Review retest outcome

Follow the path `Fix task or customer evidence → Retest request → Retest scan run → Retest outcome → Issue state or monitoring conversion`.

1. Open /fix-tasks/{fixTask} after an approved change or customer-applied evidence exists. Result: the fix task shows the issue, submitted evidence and retest eligibility before a retest is trusted.
2. Start or open the completed retest run from the fix task. Result: retest_scan_run_id and retest_requested_at are tied to the same issue_fingerprint and project scope.
3. Read retest_status before changing the issue state. Result: passed, failed, pending or inconclusive outcome is visible instead of inferred from a note.
4. For a passed retest, confirm the original fingerprint is absent and evidence collection succeeded. Result: the resolved state can move to Issue change states or monitoring conversion.
5. For a failed retest, open the remaining evidence before creating more work. Result: recurring evidence goes back to fix tasks or ticket-only fallback with the exact observed blocker.
6. For pending or inconclusive retests, use the blocked reason before continuing. Result: missing artifacts, unavailable scan runs or changed scope go to Inconclusive evidence instead of a false resolved claim.

Outcome meanings

Use the outcome to choose the next automated action.

• Passed retest means the original issue_fingerprint was not observed in the retest scan and evidence collection was sufficient.
• Failed retest means the same issue_fingerprint or equivalent evidence still appears and more remediation is needed.
• Pending retest means the retest scan has not completed and the issue state should not be changed yet.
• Inconclusive retest means the retest did not collect enough evidence to prove the original issue disappeared.
• Skipped retest means plan, scope, scan availability or task state prevented the retest from running.

Blocked or inconclusive states

Keep blocked outcomes explicit before reporting a fix as passed or failed.

• Retest not ready means wait for the scan run to complete before using retest_status.
• Inconclusive retest means send the customer to Inconclusive evidence instead of claiming resolved.
• Failed retest means continue the existing fix task or create a ticket-only fallback when connected access is unavailable.
• Scope changed means the retest did not cover the same accepted project pages as the original issue.
• Evidence missing means screenshot, HTML, console or network artifacts were not collected for the claim.
• Package unavailable means billing or entitlement state blocks the retest run.

Continue by outcome

Passed outcomes can continue to Issue change states or Retests and monitoring conversion. Failed outcomes continue to Fix tasks or Ticket-only fallback. Pending, skipped or inconclusive outcomes continue to Inconclusive evidence before any resolved claim is shown. Use Scheduled scans only after the fix has a supported outcome and the project is ready for recurring monitoring.