feat(designer) - Show operation default setting values and host settings in the designer#9253
feat(designer) - Show operation default setting values and host settings in the designer#9253JoaquimMalcampo wants to merge 14 commits into
Conversation
🤖 AI PR Validation ReportPR Review ResultsThank you for your submission! Here's detailed feedback on your PR title and body compliance:✅ PR Title
✅ Commit Type
✅ Risk Level
✅ What & Why
✅ Impact of Change
✅ Test Plan
|
| Section | Status | Recommendation |
|---|---|---|
| Title | ✅ | No change required |
| Commit Type | ✅ | No change required |
| Risk Level | ✅ | No change required |
| What & Why | ✅ | No change required |
| Impact of Change | ✅ | No change required |
| Test Plan | ✅ | Unit tests are present; no further action needed |
| Contributors | Optional, but add contributors if applicable | |
| Screenshots/Videos | ✅ | No change required |
Overall, this PR passes review. The advised risk level does not need to be increased beyond the submitter's Medium selection.
Last updated: Fri, 19 Jun 2026 16:28:17 GMT
There was a problem hiding this comment.
Pull request overview
This PR enhances the Designer settings panel to display concrete default operation setting values returned by the backend settingDefaults API (instead of an opaque “Default”), and surfaces unknown host-level settings in a new read-only “Host settings” section—while keeping workflow JSON serialization behavior unchanged.
Changes:
- Add a React Query–cached
settingDefaultsfetch + merge path during operation initialization/deserialization. - Extend settings types (
SettingData,Settings,SettingSectionName) to support read-only/default-hint semantics and host-level settings display. - Add a new Settings panel section to render host-level settings as read-only text fields.
Reviewed changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| Localize/lang/strings.json | Adds localization entry for the new “Host settings” section title. |
| libs/logic-apps-shared/src/designer-client-services/lib/operationmanifest.ts | Extends the operation manifest service interface with optional getSettingDefaults. |
| libs/logic-apps-shared/src/designer-client-services/lib/standard/operationmanifest.ts | Implements getSettingDefaults for Standard (including hybrid proxy path). |
| libs/logic-apps-shared/src/designer-client-services/lib/consumption/operationmanifest.ts | Implements getSettingDefaults for Consumption using the existing baseUrl/connectorId URL pattern. |
| libs/designer/src/lib/ui/settings/sections/hostsettings.tsx | New UI section that renders host-level settings as read-only fields. |
| libs/designer/src/lib/ui/settings/index.tsx | Wires the new Host Settings section into the Settings panel and centralizes SettingSectionName. |
| libs/designer/src/lib/core/state/setting/settingInterface.ts | Adds HOSTSETTINGS to the settings section name map. |
| libs/designer/src/lib/core/queries/settingDefaults.ts | Adds supported-settings key extraction, React Query fetch, and merge logic (including hostSettings routing). |
| libs/designer/src/lib/core/actions/bjsworkflow/settings.ts | Extends settings types to support readOnly, defaultHint, and hostSettings. |
| libs/designer/src/lib/core/actions/bjsworkflow/serializer.ts | Avoids serializing retry policy when it was populated from API defaults (via defaultHint). |
| libs/designer/src/lib/core/actions/bjsworkflow/operationdeserializer.ts | Fetches and merges setting defaults during manifest-based operation initialization. |
| libs/designer/src/lib/core/actions/bjsworkflow/add.ts | Fetches and merges setting defaults during operation creation/initialization flows. |
| libs/designer-v2/src/lib/core/actions/bjsworkflow/settings.ts | Adds readOnly to v2 SettingData to keep parity for read-only settings support. |
📊 Coverage CheckThe following changed files need attention:
Please add tests for the uncovered files before merging. |
…thub.com/Azure/LogicAppsUX into jmalcampo/nodeSettingDetailsEnhancements
| ); | ||
|
|
||
| settings = addDefaultSecureSettings(settings, connector?.properties?.isSecureByDefault ?? false); | ||
| const swaggerDefaults = await fetchSettingDefaults( |
There was a problem hiding this comment.
mcpDefaults, manifestDefaults, and swaggerDefaults are fetched the same. Can these be combined earlier in the method?
| import { getReactQueryClient } from '../ReactQueryProvider'; | ||
| import Constants from '../../common/constants'; | ||
|
|
||
| const KNOWN_SETTING_KEYS = new Set<string>([ |
There was a problem hiding this comment.
how is the settings view usually updated with new settings? Is it possible that this list will fall out of sync if another setting is added elsewhere? If possible, we should be pulling these values from some source of truth rather than hardcoded here
| supportedSettings: string[], | ||
| workflowKind?: string | ||
| ): Promise<Record<string, any> | undefined> => { | ||
| const service = OperationManifestService(); |
There was a problem hiding this comment.
nit: 'service' is vague here
| queryParameters: { 'api-version': apiVersion }, | ||
| content: { settings: supportedSettings, workflowKind }, | ||
| }); | ||
| } catch { |
There was a problem hiding this comment.
are there any exceptions which should be surfaced here rather than silently failing
| if (isReadOnly) { | ||
| (merged as Record<string, unknown>)[settingKey] = { ...existing, value: defaultValue, readOnly: true }; | ||
| } else if (settingKey === 'retryPolicy' && isDefaultRetryPolicy(existing.value)) { | ||
| (merged as Record<string, unknown>)[settingKey] = { ...existing, value: defaultValue, defaultHint: defaultValue }; |
There was a problem hiding this comment.
Is retryPolicy the only setting that uses defaultHint? I see it's included on the SettingData interface but only see usages for this setting
|
some of the copilot comments seem valid |
…st settings circular import
…derive known keys from settings, log setting-default fetch failures
…keyed backend route
HTTP-family built-ins (Http, HttpWebhook, ApiConnection, ApiConnectionWebhook, OpenApiConnection, OpenApiConnectionWebhook) are synthetic on the client and not resolvable through the operationGroups catalog, so the connector route fails backend validation for them. Thread the node operationType through applySettingDefaults and select operationTypes/{operationType}/settingDefaults for these types; all catalog-resolvable operations keep the existing operationGroups route. Skip the fetch entirely for no-retry types (Request, Response, Schedule, DateTime, Compose, control/variable actions).
Commit Type
Risk Level
What & Why
Adds UI visibility for operation setting defaults returned by the settingDefaults API. Previously, settings like retry policy showed "Default" with no detail fields when no explicit value was set in the workflow definition. Now the designer fetches defaults from the host and displays actual values (e.g., "Exponential interval", count, intervals) while preserving the existing serialization behavior — no changes are written to the workflow JSON.
Additionally, unknown host-level settings returned by the API (e.g., maxMessageBatchSize) are now surfaced in a new read-only "Host settings" section in the settings panel.
Changes
Impact of Change
Settings panel now shows actual default values for retry policy and other settings instead of an opaque "Default" label. Host-level read-only settings (e.g., maxMessageBatchSize) are visible in a new collapsible section. No changes to saved workflow definitions.
New defaultHint field on SettingData — indicates the value came from API defaults and should not be serialized. hostSettings on Settings is a dynamic Record<string, SettingData> for arbitrary host-returned keys. KNOWN_SETTING_KEYS set in settingDefaults.ts controls which API keys are treated as known vs host-level.
One additional HTTP call per operation during deserialization (cached by React Query). No changes to workflow JSON serialization output.
Test Plan
Contributors
Screenshots/Videos