Preserve recoverable WordPress login exchange failures

[xrpbanks]

Scope

Fix one verified identity-exchange error-handling defect. Exactly two files change: backend/app/main.py and backend/tests/test_identity_endpoints.py.

• Preserve WordPress HTTP 429, 502, 503 and 504 as temporary callback failures instead of converting every non-200 response into a permanent 400 rejection.
• Preserve the upstream Retry-After header and restore pending login state for 429 as well as the existing transient gateway statuses.
• Keep invalid/rejected codes and replayed login states fail-closed. No schema, dependency, frontend, plugin, layout, secret or configuration changes.

Reproduction and validation

New tests exercise the real exchange adapter against synthetic HTTP responses, rather than replacing it with an already-classified exception.

• Before the fix: 4 new transient-response cases failed; 3 permanent-rejection cases passed.
• After the fix: all 7 cases passed. Each transient case verifies that the same login can complete after recovery and that subsequent replay is rejected.
• Identity suites: 176 passed.
• Full backend suite against a local SQLite test database: 953 passed, 24 skipped. One Starlette/httpx TestClient deprecation warning was observed.
• git diff --check and the tracked-secret boundary check passed.

The uploaded tree is exactly 47cb2799f438a822f74728bd9e3e0431ea39e96e, matching tested local commit 0dcfdb580a0c6b778e1911aede19a59ff8949e05. The GitHub-created commit has different metadata but identical source contents.

Release boundary

Draft for review only. Do not merge or deploy as part of opening this PR. This proves a recoverability defect and its local repair; it does not establish that production joint WordPress/CalorieApp sign-in is restored. A compatible rollout and a successful live completion check remain necessary.

[Copilot]

🟢 Approval recommended

The change is narrowly scoped, preserves fail-closed behavior for permanent rejections, and is backed by targeted tests that verify retryability, header preservation, and replay rejection.

Pull request overview

Updates the backend WordPress login code-exchange path to treat certain upstream HTTP failures as transient (retryable) rather than permanently rejecting the login, while preserving Retry-After and ensuring pending login state can be recovered and retried.

Changes:

• Classify WordPress exchange HTTP 429/502/503/504 responses as transient, returning the same status code (and Retry-After when present) instead of converting to a permanent 400.
• Extend callback transient-failure handling to restore pending login state for 429 in addition to existing gateway statuses.
• Add end-to-end identity endpoint tests that exercise the real exchange adapter against synthetic HTTP responses, validating retry completion and replay rejection.

File summaries

File	Description
backend/app/main.py	Preserves transient upstream exchange failures (including 429) and forwards Retry-After while keeping pending login state retryable.
backend/tests/test_identity_endpoints.py	Adds tests covering transient vs permanent upstream WordPress exchange responses, including Retry-After preservation and state replay protection.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.