fix: distinguish permanent and retryable token validation failures

[flcrom]

Refs #7537.

Token validation mapped every API status other than 401/403 to TokenValidationError("server error"), so a permanent failure such as a malformed request got the same "try again later" advice as a transient one.

This keeps the HTTP status and splits the result into retryable (for example 5xx) and permanent, so the guidance matches. Nothing else about validation changes.

The API's error detail is intentionally not surfaced: it can echo the token. So this covers the HTTP status and the retryable vs permanent split only, not the API's own explanation from the issue. That part of #7537 is left open, which is why this says "Refs" and not "Closes".

Added tests in tests/units/reflex_cli/utils/test_hosting.py, including checks that the token does not appear in the error. An independent review environment ran them with the existing unit suite (790 passed); I did not run them myself. I did not run lint or the full CI matrix locally; CI will.

News fragment included.

All Submissions:

• Have you followed the guidelines stated in CONTRIBUTING.md file?
• Have you checked to ensure there aren't any other open Pull Requests for the desired changed?

Type of change

• Bug fix (non-breaking change which fixes an issue)

[cubic-dev-ai]

1 issue found across 4 files

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Re-trigger cubic</sub>

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/reflex-hosting-cli/src/reflex_cli/utils/exceptions.py">

<violation number="1" location="packages/reflex-hosting-cli/src/reflex_cli/utils/exceptions.py:19">
P2: `TokenAccessDeniedError` inherits this `True` default even though `_validate` uses it for 401/403 refusals, so callers inspecting `retryable` can wrongly treat a rejected token as retryable. Set this subclass's value to `False`.</violation>
</file>

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no blocking issues were found.

Summary

Token validation now reports the HTTP status and suggests retrying only for failures that may succeed later.

• Token validation reports HTTP status and gives retry advice only when it may help.

_{Reviews (2) · Last reviewed commit: "fix: mark rejected tokens as not retryab..." · Reviewed by Greptile}

[codspeed]

Merging this PR will not alter performance

⚠️ 15 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

• test_get_state[memory]
• test_cli_startup[deploy_help]
• test_event_queue_dispatch
• test_emit_update
• test_import_cli
• test_set_state[disk]
• test_cli_startup[version]
• test_cli_startup[help]
• test_modify_state[disk]
• test_event_shutdown_cancel
• …and 5 more

✅ 148 untouched benchmarks

---

_{Comparing flcrom:fix-token-validation-errors (da880d9) with main (2eb1b44)}