test(e2e): accept 422 alongside 404 for unfetchable page

[ilya-bogin-keenable]

What

Unblocks test_dead_page, which pins the error string for a dead page to Not found while the API now answers Unprocessable entity. Both are valid "this page can't be fetched" outcomes, so the test accepts either; the CLI contract it actually guards — exit code 1 plus a structured error — is unchanged.

This is the patch that has been sitting on fix/dead-page-422 since 2026-06-30, replayed onto current main. The old branch was based on bd7e8b4 and had diverged (its remote and local tips were the same patch twice over), so it's cleaner to land it from here; the original commit is preserved with its authorship.

Second commit: the comment was wrong

The original comment explained the 404-or-422 split as "depending on how far upstream got". Probing the live API today shows that isn't the mechanism — /v1/fetch answers 422 with The page was reached but content could not be extracted for every unfetchable input, including https://this-domain-does-not-exist-zzz999.com/page, where nothing was reached and the message is simply false. The comment now says that, so nobody re-tightens the assertion to 404 on the strength of a wrong explanation.

Caveat worth stating plainly

This makes the suite tolerate a backend bug rather than fix it. 422 has become a catch-all covering "not found", "host does not resolve" and "fetched but not extractable", and after this merge no test flags that. The backend issue (proposing 404 / 502 / 422 split by cause) is being filed separately — with this merged, that report is the only thing tracking it.

test_fetch_live stays red regardless: live=true returns 422 for every URL, so nightly e2e remains failing until the backend fixes the live path.

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

test(e2e): allow 422 or 404 for unfetchable fetch targets

🧪 Tests 🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Unblock test_dead_page by accepting 422 as well as 404 for unfetchable URLs.
• Update the test comment to reflect current backend behavior and known 422 catch-all bug.

Diagram

graph TD
  A["E2E: test_dead_page"] --> B["CLI: kn fetch"] --> C["Backend: /v1/fetch"] --> D{"Unfetchable?"} --> E["YAML error: 404/422"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Loosen assertion to only require structured error presence

• ➕ Maximally resilient to backend wording/status churn
• ➕ Still validates exit code == 1 and YAML shape
• ➖ Reduces coverage of user-visible error semantics (message regressions may slip)

2. Introduce/consume a stable error code field (e.g., error_code)

• ➕ Keeps the test precise while decoupling from status/message text
• ➕ Improves CLI contract clarity for downstream tooling
• ➖ Requires a product/API contract change beyond this PR’s scope

3. Stub the backend in e2e for deterministic error statuses

• ➕ Eliminates flakiness due to backend behavior changes
• ➕ Allows strict assertions (status/message) without brittleness
• ➖ Less representative of real integration behavior; adds harness complexity

Recommendation: Current approach is a reasonable compromise for true e2e coverage: it keeps asserting the CLI contract (exit code 1 + structured error) while tolerating known backend inconsistency between 404 and 422. If the project wants stricter guarantees long-term, prefer adding a stable error code to the CLI/API and assert on that instead of message text.

Files changed (1) +6 / -1

Tests (1) +6 / -1

test_fetch.pyMake dead-page e2e assertion accept 404 or 422 and document backend quirk +6/-1

Make dead-page e2e assertion accept 404 or 422 and document backend quirk

• Updates 'test_dead_page' to accept either "Not found" (404) or "Unprocessable entity" (422) as valid unfetchable outcomes. Replaces the previous single-string assertion with a membership check and adds an explanatory comment describing current backend behavior and the known 422 catch-all issue.

tests/e2e/test_fetch.py

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review