Add next_flow to Repair Flows

[iluvdata]

Proposed change

Add next_flow to async_create_entry of the RepairsFlow. This allows repairs flows requiring configuration changes (for issues other than reauthentication to trigger a reconfigure or options flow for a config entry or a reconfigure flow for a subentry. This functionality was already implemented in the front end but not supported by the back end.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:
• Link to developer documentation pull request: https://github.com/home-assistant/developers.home-assistant/pull/2985
• Link to frontend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository. (Will update)

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (repairs) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of repairs can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign repairs Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component, problem in config, problem in device, feature-request) on the pull request.

[Copilot]

Pull request overview

This PR adds support for next_flow in the async_create_entry method of RepairsFlow. When a repair issue fix requires configuration changes, the flow can now trigger a subsequent reconfigure, options, or config subentry flow. The frontend already supported this feature; this PR adds the required back-end support.

Changes:

• FlowType enum extended with OPTIONS_FLOW and CONFIG_SUBENTRIES_FLOW values (previously only CONFIG_FLOW existed)
• RepairsFlow.async_create_entry now accepts an optional next_flow parameter, validates it (ensuring the referenced flow exists and is a reconfigure or options flow), and includes it in the result
• HTTP views updated to serialize the result for the frontend when next_flow is present

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
homeassistant/config_entries.py	Adds OPTIONS_FLOW and CONFIG_SUBENTRIES_FLOW values to FlowType enum; minor whitespace fix
homeassistant/components/repairs/models.py	Introduces RepairsFlowResult typed dict; adds next_flow parameter to async_create_entry; validates and sets next_flow and result in the flow result
homeassistant/components/repairs/websocket_api.py	Adds _prepare_repairs_flow_result_json helper to serialize the ConfigEntry result for the frontend; overrides _prepare_result_json in both view classes
tests/components/repairs/test_websocket_api.py	Adds comprehensive test cases for next_flow functionality including valid and invalid scenarios for all three flow types

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[gjohansson-ST]

Given that we once changed from FlowResult to ConfigFlowResult for config flows, I'm guessing it's not a far fetch to say we should do same here.
Could be done in a preliminary PR and then expand it here as needed.

[cdce8p]

Given that we once changed from FlowResult to ConfigFlowResult for config flows, I'm guessing it's not a far fetch to say we should do same here. Could be done in a preliminary PR and then expand it here as needed.

I agree. A good comparison IMO is the SubentryFlowResult. Each subclass of ConfigSubentryFlow only returns that one in its methods. Should be similar here for RepairsFlowResult. It's just a bit more effort now.

The suggestion from @gjohansson-ST is probably the most workable. You could even start with just a type alias for RepairsFlowResult and then use that in all RepairsFlow subclasses. Afterwards, this PR could then convert the type alias to a TypedDict.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.