feat(designer): Add HTTP status codes configuration to retry policy settings

[swghimire]

Commit Type

• feature - New functionality

Risk Level

• Low - Minor changes, limited scope

What & Why

Adds support for configuring HTTP status codes that should trigger retries in the retry policy settings. This allows users to specify which HTTP error codes (4xx and 5xx) should cause the action to retry, providing more granular control over retry behavior.

Previously, retry policies only supported count, interval, minimum/maximum interval, and policy type. This change adds a new httpStatusCodes parameter that lets users select specific HTTP status codes that trigger retries.

Changes

• New file: libs/designer-ui/src/lib/settings/settingsection/settingtagpicker.tsx — Reusable tag picker component for multi-select dropdown with tag display
• Modified: libs/logic-apps-shared/src/utils/src/lib/models/logicAppsV2.ts — Extended RetryPolicy type with httpStatusCodes?: number[]
• Modified: libs/designer/src/lib/ui/settings/sections/networking.tsx — Added HTTP status codes setting to retry policy section
• Modified: libs/designer-v2/src/lib/ui/settings/sections/networking.tsx — Added HTTP status codes setting to retry policy section (v2)
• Modified: libs/designer/src/lib/ui/settings/settingsection.tsx — Added SettingTagPicker rendering case
• Modified: libs/designer-v2/src/lib/ui/settings/settingsection.tsx — Added SettingTagPicker rendering case (v2)
• Modified: libs/designer/src/lib/ui/settings/index.tsx — Added handler for httpStatusCodes changes
• Modified: libs/designer-v2/src/lib/ui/settings/index.tsx — Added handler for httpStatusCodes changes (v2)
• Modified: libs/designer/src/lib/core/actions/bjsworkflow/settings.ts — Added serialization for httpStatusCodes
• Modified: libs/designer-v2/src/lib/core/actions/bjsworkflow/settings.ts — Added serialization for httpStatusCodes (v2)
• New file: libs/designer-ui/src/lib/settings/settingsection/__tests__/settingtagpicker.spec.tsx — Unit tests for SettingTagPicker component

Impact of Change

• Users: Users can now configure which HTTP status codes trigger retries in the retry policy settings. A new dropdown with tag picker UI allows selecting from all standard 4xx and 5xx HTTP status codes.
• Developers: New SettingTagPicker component available for reuse in other multi-select scenarios. New onRetryHttpStatusCodesChange handler in settings interface.
• System: No performance or architecture impact. Extends existing retry policy serialization.

Test Plan

• Unit tests added/updated
• E2E tests added/updated
• Manual testing completed
• Tested in: Standalone designer (localhost:4200)

Contributors

Screenshots/Videos

[github-actions]

🔒 AI Validation Pending

This PR is from an external contributor. AI validation will be performed after manual review by a maintainer.

Maintainers: Add the external-approved label to this PR after reviewing the changes to enable AI validation.

[Copilot]

Pull request overview

Adds support for configuring a retry policy HTTP status-code allowlist in the Logic Apps designer settings UI and workflow model, including a new tag-picker control for multi-select input.

Changes:

• Extends RetryPolicy models/serialization to include httpStatusCodes?: number[].
• Adds a reusable SettingTagPicker control to @microsoft/designer-ui and wires it into both designer (v1) and designer-v2 networking settings.
• Adds new localized strings for the new retry policy setting label/tooltip/placeholder.

Reviewed changes

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

Show a summary per file

File	Description
libs/logic-apps-shared/src/utils/src/lib/models/logicAppsV2.ts	Adds httpStatusCodes to the shared RetryPolicy model.
libs/designer/src/lib/ui/settings/settingsection.tsx	Supports rendering the new SettingTagPicker setting type.
libs/designer/src/lib/ui/settings/sections/networking.tsx	Adds “HTTP status codes” retry policy setting (tag picker) to Networking section.
libs/designer/src/lib/ui/settings/index.tsx	Persists selected HTTP status codes into node settings state.
libs/designer/src/lib/core/actions/bjsworkflow/settings.ts	Deserializes httpStatusCodes from workflow definition into settings.
libs/designer-v2/src/lib/ui/settings/settingsection.tsx	Supports rendering the new SettingTagPicker setting type.
libs/designer-v2/src/lib/ui/settings/sections/networking.tsx	Adds “HTTP status codes” retry policy setting (tag picker) to Networking section.
libs/designer-v2/src/lib/ui/settings/index.tsx	Persists selected HTTP status codes into node settings state.
libs/designer-v2/src/lib/core/actions/bjsworkflow/settings.ts	Deserializes httpStatusCodes from workflow definition into settings.
libs/designer-ui/src/lib/settings/settingsection/settingtagpicker.tsx	Introduces the new tag picker setting control.
libs/designer-ui/src/lib/settings/settingsection/index.tsx	Exports SettingTagPicker and related types.
libs/designer-ui/src/lib/settings/settingsection/tests/settingtagpicker.spec.tsx	Adds initial unit tests for SettingTagPicker.
libs/designer-ui/src/lib/settings/settingsection/tests/snapshots/settingtagpicker.spec.tsx.snap	Snapshot for SettingTagPicker initial render.
Localize/lang/strings.json	Adds localized strings for the new retry policy setting label/tooltip/placeholder.

[github-actions]

🤖 AI PR Validation Report

PR Review Results

Thank you for your submission! Here's detailed feedback on your PR title and body compliance:

✅ PR Title

• Current: feat(designer): Add HTTP status codes configuration to retry policy settings
• Issue: The title is clear, follows conventional commit style, and succinctly describes the change.
• Recommendation: Keep as-is. Optionally, if you want to emphasize both designer and designer-v2, you could add (designer/designer-v2) in the scope, but this is optional.

---

⚠️ Commit Type

• Properly selected (feature).
• Note: Only one option is selected which is correct.

---

⚠️ Risk Level

• The PR body marks Low and the PR has a risk:low label. However, based on the code diff I advise risk:medium.
• Reason: This change touches UI, localization, shared models, and serialization logic for retry policies across both designer and designer-v2. It introduces a new serialized field (httpStatusCodes) and updates the getRetryPolicy serialization path in both designer and designer-v2 code paths. While the change is additive, the serialization and runtime behavior for retry policies could affect workflow execution if the field is incorrectly populated or interpreted. Because core action settings and serialization were modified, I recommend a higher risk rating (medium) until this lands and is validated in broader integration or E2E tests.
• Recommendation: Update the PR body Risk Level to Medium and ask a maintainer to update the PR labels to risk:medium (remove risk:low) or leave a comment explaining why risk:low is acceptable if you disagree.

---

✅ What & Why

• Current: "Adds support for configuring HTTP status codes that should trigger retries in the retry policy settings..." with a clear list of changed files.
• Issue: None — the description is concise and lists important changed files.
• Recommendation: Good. Consider calling out whether this change is behind any feature flag (if applicable) and whether existing persisted settings without httpStatusCodes continue to behave the same (they appear to do so, but a short sentence confirming backward compatibility would help reviewers).

---

✅ Impact of Change

• Impact section is present and appropriately describes Users/Developers/System.
• Recommendation:
  • Users: No change required; they can now select HTTP status codes to retry.
  • Developers: Note that a new SettingTagPicker is available and new handler onRetryHttpStatusCodesChange was added.
  • System: Confirmed no major architecture changes, but please add a sentence confirming backward compatibility of existing retry policies without the new field.

---

✅ Test Plan

• Unit tests added/updated: ✅ (there is a new SettingTagPicker unit test & snapshot)
• E2E tests: not added — acceptable for this UI + model update if you document manual testing and rationale.
• Manual testing: marked as completed and tested locally — good.
• Recommendation: Consider adding a small E2E test or integration test that verifies that httpStatusCodes are persisted in the serialized retry policy (if you have test infra for that), since this touches serialized configuration used at runtime.

---

⚠️ Contributors

• Current: (blank)
• Assessment: Optional. If others (PMs, designers, reviewers) contributed, add them here. If none, you can leave blank but consider crediting reviewers/PMs when appropriate.

---

⚠️ Screenshots/Videos

• Current: Descriptive text only (no screenshots). For a UI change showing a tag picker with many options, screenshots are optional but helpful.
• Recommendation: Add a screenshot of the dropdown and selected tags if you want faster visual review; not required to pass.

---

Summary Table

Section	Status	Recommendation
Title	✅	Keep current title (optional: include both designer/designer-v2 in scope)
Commit Type	⚠️	Proper (feature) — no action needed
Risk Level	⚠️	Change to Medium in PR body and update label to risk:medium (see reasoning)
What & Why	✅	Good — add one line about backward compatibility if possible
Impact of Change	✅	Good — add confirmation that old retry policies remain unaffected if applicable
Test Plan	✅	Unit tests exist — consider adding an integration/E2E test for serialized httpStatusCodes
Contributors	⚠️	Optional: add contributors or leave blank with reminder to credit when applicable
Screenshots/Videos	⚠️	Optional: add screenshot(s) for UI reviewer convenience

---

Final Message
This PR passes the Title and Body template checks. The main actionable item is to update the risk level to Medium (and the corresponding label) because serialization and runtime-relevant fields were changed across multiple modules. Please update the PR Risk Level section to select Medium and either update/remove the risk:low label or add an explanation for why risk:low is still accurate. Additionally, please consider:

• Adding a short note in What & Why confirming backward compatibility for existing retry policies that do not include httpStatusCodes.
• Optionally adding an integration/E2E test to assert that httpStatusCodes are serialized and deserialized as expected in runtime payloads, or documenting why E2E isn't necessary.
• Optionally adding a screenshot of the settings UI to make UI review faster.

Once you update the PR risk level and labels (or provide justification), re-request review. Thanks for the thorough PR — the implementation, tests, and localization updates look solid.

---

Last updated: Thu, 26 Mar 2026 21:25:14 GMT