Ask for the email in the reauth flow, and add a reconfigure step - #4
Merged
Merged
Conversation
async_step_reauth_confirm asked only for the password and reused the email
stored on the config entry. An entry whose data carries no email, which is
what an entry written before the email was stored looks like, then passed an
empty string to FitdaysClient.login. The client raises FitdaysValidationError
at client.py:109 before it contacts the cloud, the flow mapped that to the
"unknown" error key, and the form showed "Unexpected error." with no way to
recover the entry.
The reauth form now asks for the email as well, prefilled from the entry when
it has one. FitdaysValidationError maps to invalid_auth, because blank input
is a form problem and not an outage.
The flow also had no async_step_reconfigure, so the entry could not be pointed
at fresh credentials at all. Added one. It refuses credentials whose uid
differs from the entry's unique_id, because reconfigure repairs one account's
entry and a second account belongs in its own entry.
Verified on ha-dev (HA 2026.8.3, podman container ha-dev on nix1):
- the entry now reports supports_reconfigure true
- the reconfigure form renders email (required), password (password selector),
country (optional, default NL)
- submitting a blank email, the exact input that produced "Unexpected error.",
returns errors {"base": "invalid_auth"} on both the reconfigure and the
reauth step, and logs no ERROR line
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
nl.json still described the reauth step as password-only and had no reconfigure step, so a Dutch user would have seen the new email field and the reconfigure form fall back to English. The key sets of en.json and nl.json now match exactly, checked by comparing them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What broke
Reconfiguring the Fitdays entry on my dev instance showed "Unexpected error." Three receipts:
home-assistant.log—ERROR [custom_components.fitdays.config_flow] Unexpected Fitdays error during login: email and password are required{'email': None, 'password_hash': None, 'refresh_token': None, 'token': SET, 'uid': SET}fitdays/client.py:109—if not email or not password: raise FitdaysValidationError("email and password are required")async_step_reauth_confirmasked only for the password and reused the email stored on the entry. With no email on the entry it passed""toFitdaysClient.login, the client raisedFitdaysValidationErrorbefore contacting the cloud, and theexcept FitdaysErrorbranch mapped it to theunknownkey, whichstrings.jsonrenders as "Unexpected error." The entry could not be recovered from the UI at all.There was also no
async_step_reconfigure, so the entry could not be pointed at fresh credentials.What changed
FitdaysValidationErrormaps toinvalid_auth. Blank input is a form problem, not an outage.async_step_reconfiguretaking email, password and country. It aborts withaccount_mismatchwhen the returned uid differs from the entry'sunique_id, because reconfigure repairs one account's entry and a second account belongs in its own entry._credentials_schema()builds the one form all three steps use.strings.jsonandtranslations/en.jsongain thereconfigurestep and thereconfigure_successfulandaccount_mismatchaborts.Verified on ha-dev
HA 2026.8.3, podman container
ha-devon nix1, running this branch's files.supports_reconfigure: truePOST /api/config/config_entries/flowwith the entry id returnsstep_id: reconfigurewith fields email (required), password (password selector), country (optional, default NL)errors {"base": "invalid_auth"}on both the reconfigure and the reauth stepgrep -c 'Unexpected Fitdays error'on the log after those submits: 0The successful-login path is not exercised, because the dev entry holds an expired hand-seeded token with no credentials and I have no Fitdays account credentials to hand.
Independent of #3; branched from
main.🤖 Generated with Claude Code