fix(wordpress): treat REST API 404 as non-retryable

[Gilbert09]

Problem

The WordPress data warehouse source raises an uncaught HTTPError when a wp/v2 collection returns 404. Seen in error tracking on the /users endpoint:

HTTPError: 404 Client Error: Not Found for url: <redacted>/wp-json/wp/v2/users?per_page=100&orderby=id&order=asc

It originates in wordpress.py fetch_page at response.raise_for_status(), so the sync fails and Temporal retries it repeatedly — burning retries and re-surfacing as error-tracking noise — for a condition that will never resolve on its own.

A per-endpoint 404 here is a customer-side config issue, not our bug. The base site URL is already validated against /posts at source setup, so by sync time the REST root is known-good. A 404 on a specific collection means that collection is disabled or blocked on the site. This is very common for /wp-json/wp/v2/users, which security plugins and managed hosts routinely block to prevent user enumeration.

Error tracking issue: https://us.posthog.com/project/2/error_tracking/019f26df-2192-7bf0-8c1f-7323cef731f5

Changes

Add 404 Client Error to WordpressSource.get_non_retryable_errors, mirroring the existing 401/403 entries. The sync stops retrying, disables the affected schema, and surfaces an actionable message pointing at the blocked endpoint (and how to fix it or drop the table from the sync) instead of a raw stack trace.

Scoped strictly to this: the substring 404 Client Error is stable and carries no volatile URL, id, or timestamp. It disables only the failing schema, not the whole source, so other collections keep syncing.

How did you test this code?

Automated tests only (agent — no manual sync performed):

• Extended the existing parametrized TestWordpressSource::test_non_retryable_errors with a 404 Client Error case. It guards the regression where someone drops the 404 mapping and WordPress imports against a site that blocks a collection retry indefinitely. Extended rather than added a new function since the assertion is identical to the 401/403 cases.
• Ran the test (3 passed) and ruff check / ruff format on the two changed files.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

No docs change needed. The in-product source caption is unchanged and still accurate; this only affects the runtime error message on a failed sync.

🤖 Agent context

Autonomy: Fully autonomous

Authored by Claude Code (Opus 4.8) from an error-tracking webhook. Invoked the /writing-tests skill before touching the test file to apply the value gate — the change is a single parametrized case, not a new test.

Decision: I weighed a graceful per-endpoint skip vs. marking 404 non-retryable, and chose non-retryable. A 404 is deterministic (retrying can't help) and, since the REST root is already validated at setup, a sync-time 404 is a blocked/disabled collection — an upstream config issue best surfaced to the user with the schema disabled, exactly like the existing 401/403 handling. Checked against open PR #68046, which only reworks the 403 messaging and does not touch 404, so this is not a duplicate.

[github-actions]

Hey @Gilbert09! 👋

It looks like your git author email on this PR isn't your @posthog.com address (owerstom@gmail.com). Since you're on the PostHog team, it's worth pointing your local git author email at your @posthog.com address. Why it matters:

• Consistent work identity in git history — internal tooling that attributes commits to team members keys off your @posthog.com address.
• Keeps team contributions easy to tell apart from external community ones when scanning history.

You can fix it for this repo with:

git config user.email "you@posthog.com"

Or set it globally with git config --global user.email "you@posthog.com". No need to redo this PR — just a nudge for next time. 🙂

[greptile-apps]

_{Reviews (1): Last reviewed commit: "fix(wordpress): treat REST API 404 as no..." | Re-trigger Greptile}

[github-actions]

Trivial, well-scoped fix adding a non-retryable error mapping with matching test update; author owns the code and bot reviewers (greptile, hex-security) signaled approval.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-03 09:17 UTC	Run
prod-us	✅ Deployed	2026-07-03 09:38 UTC	Run
prod-eu	✅ Deployed	2026-07-03 09:43 UTC	Run