Failed scan nukes existing blocker IDs

[kokimo1]

Describe the bug
When a follow-up Equalify scan fails due to timeout or 503, the previous scan data is lost: that is, each failed url's previous total blocker count is set to 0, and its associated blocker IDs become inaccessible ("Blocker not found").

To Reproduce
Steps to reproduce the behavior:

1. Go to existing audit containing reported blockers (e.g., see "UIC - SDD - Red template tracking" https://app.equalify.uic.edu/audits/3174659f80c84148af89f4b220fec47d, this is an audit that had 245 template-level blockers in July 28, 2026)
2. Run a new scan while the target site is unreachable or timing out. Red's host (Pantheon) is having issues right now, so scans of any Red-hosted sites are likely to fail.
3. Note the scan completes and then reports 0 blockers. Also, any blocker URL from previous scan no longer loads (e.g., https://app.equalify.uic.edu/shared/3174659f80c84148af89f4b220fec47d/XSYR7458 returns "Blocker XSYR7458 not found.")

Expected behavior
Failed scan shouldn't overwrite previous blocker data.

Desktop (please complete the following information):

• OS: macOS
• Browser: Chrome
• Version: 137

Additional context
Scan history for audit "UIC - SDD - Red template tracking":

Date	URLs	Blockers
Jul 28, 2026	32	245
Aug 28, 2026 (auto)	32	0
Aug 31, 2026 (manual)	32	0
Sep 1, 2026 (manual)	32	0

• "UIC - SDD - Red template tracking" audit URL: https://app.equalify.uic.edu/audits/3174659f80c84148af89f4b220fec47d

• Example dead blocker links (valid before Aug 28):

  • https://app.equalify.uic.edu/shared/3174659f80c84148af89f4b220fec47d/ZJGL6225 ("Elements must only use permitted ARIA attributes" violation on https://red.uic.edu/all-component-page/#map, internal SDD ticket RAAS-292)
  • https://app.equalify.uic.edu/shared/3174659f80c84148af89f4b220fec47d/VEOO4473 ("Ensure all page content is contained by landmarks" violation on https://meng.uic.edu, internal SDD ticket RAAS-286)

• Related: issue #628, similar data loss pattern, IDK if same root cause

[heythisischris]

Hi @kokimo1,

Thank you for the bug report! First- your previous scan data wasn't "truly" deleted, it got moved to an archive table when a newer scan completes, so your July blockers (and their IDs) are fully recoverable.

That said, a failed scan definitely shouldn't wipe out the previous results like this. Fixing it involves a few fundamental changes with handling errored scans- it's also highlighted the need for users to be able to retrieve previously archived scans themselves.

We're currently investigating / addressing. I'll let you know as soon as there's an update.

Thanks,
Chris

[kokimo1]

Hey Chris,

got moved to an archive table when a newer scan completes, so your July blockers (and their IDs) are fully recoverable

currently investigating / addressing. I'll let you know as soon as there's an update.

Ah, this is good to know, thank you!