feat(orchestrator): add fetch:error:ignoreUnready and fetch:response:default options for form widgets

[lokanandaprabhu]

Hey, I just made a Pull Request!

Fixes:
https://issues.redhat.com/browse/RHDHBUGS-2454
https://issues.redhat.com/browse/RHDHBUGS-2453

This PR introduces two new ui:props options for the orchestrator form widgets to improve user experience when working with dynamic forms that depend on fetch operations.

---

Feature 1: fetch:error:ignoreUnready

Problem: When using widgets with fetch:retrigger dependencies, the initial fetch often fails because dependent fields don't have values yet. This results in HTTP errors (e.g., 404, 400) being displayed to users during initial load, even though this is expected behavior.

Solution: Added fetch:error:ignoreUnready option that suppresses fetch error display until all fetch:retrigger dependencies have non-empty values.

Behavior:

• When true, errors are hidden while dependencies are empty
• Once all dependencies have values, errors are shown normally
• Supported by: ActiveTextInput, ActiveDropdown, ActiveMultiSelect, SchemaUpdater

---

Feature 2: fetch:response:default

Problem: Widgets previously required fetch:response:value for default values, meaning a fetch must succeed for any default to be applied.

This was problematic when:

• You want a static fallback default when fetch fails or hasn't completed
• You want to pre-populate a field without requiring a fetch
• The fetch depends on fields that aren't filled yet

Solution: Added fetch:response:default option for static default values applied immediately on form initialization.

Key Implementation Details:

• Defaults are extracted from schema and applied at form initialization level (in OrchestratorForm), not inside widgets
• This ensures controlled components work correctly and values persist across wizard step navigation
• Static defaults act as fallback when fetch fails, hasn't completed, or returns empty
• Fetched values only override defaults when non-empty
• Loading spinners are skipped when static defaults exist for instant display

Supported Types:
ActiveTextInput: string (e.g., "create")
ActiveDropdown: string (e.g., "default-profile")
ActiveMultiSelect: string[] (e.g., ["tag1", "tag2"])

---

---

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or Updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)

[rhdh-gh-app]

Important

This PR includes changes that affect public-facing API. Please ensure you are adding/updating documentation for new features or behavior.

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-orchestrator-form-react	workspaces/orchestrator/plugins/orchestrator-form-react	minor	v2.4.0
@red-hat-developer-hub/backstage-plugin-orchestrator-form-widgets	workspaces/orchestrator/plugins/orchestrator-form-widgets	minor	v1.5.0

[mareklibra]

The fetch:error:skip name can be confusing, what about fetch:error:ignoreUnready?

The point is to make clear that the error is skipped only at the beginning of the flow, not later when either data or server issues occur.

[mareklibra]

Next, I'm thinking about the extractStaticDefaults.ts - do we need to pass through the whole tree again? Could the static defaults be set when instantiating the widgets?

This way, we are reimplenting the tree walk, including the (complex) logic around allOf/oneOf/anyOf which might become harder to maintain in the future. Just thinking aloud, leaving it up to your consideration.

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[lokanandaprabhu]

@mareklibra , thanks for your feedback.

The fetch:error:skip name can be confusing, what about fetch:error:ignoreUnready?
The point is to make clear that the error is skipped only at the beginning of the flow, not later when either data or server issues occur.

Updated the PR and renamed to fetch:error:ignoreUnready.

For below query,

Next, I'm thinking about the extractStaticDefaults.ts - do we need to pass through the whole tree again? Could the static defaults be set when instantiating the widgets?
This way, we are reimplenting the tree walk, including the (complex) logic around allOf/oneOf/anyOf which might become harder to maintain in the future. Just thinking aloud, leaving it up to your consideration.

Why form-level defaults over widget-level:

The main issue is field dependencies. If field B's fetch depends on field A's value, and field A has a static default:

Widget-level: Both widgets render at the same time, so field B's fetch fires before field A's default is set → causes an extra failed fetch, then a refetch.

Form-level: Defaults are set in formData before any widget renders → field B's fetch uses the correct value immediately.

Form-level ensures all widgets see the complete initial state from their first render.