Skip to content

fix(designer): Fix infinite recursive nesting in monitoring run history values [hotfix]#9124

Closed
takyyon wants to merge 1 commit into
hotfix/v5.294from
hotfix/v5.294-monitoring-fix
Closed

fix(designer): Fix infinite recursive nesting in monitoring run history values [hotfix]#9124
takyyon wants to merge 1 commit into
hotfix/v5.294from
hotfix/v5.294-monitoring-fix

Conversation

@takyyon
Copy link
Copy Markdown
Contributor

@takyyon takyyon commented Apr 29, 2026 •
edited
Loading

Commit Type

  • feature - New functionality
  • fix - Bug fix
  • refactor - Code restructuring without behavior change
  • perf - Performance improvement
  • docs - Documentation update
  • test - Test-related changes
  • chore - Maintenance/tooling

Risk Level

  • Low - Minor changes, limited scope
  • Medium - Moderate changes, some user impact
  • High - Major changes, significant user/system impact

Cherry-pick of #9123 onto hotfix/v5.294 for immediate release.

What & Why

Problem

Multiple customers (including US Government tenants) reported that action input/output values in the workflow run history view scroll infinitely, making them unreadable. The values display as deeply nested recursive JSON with {displayName, value} objects nested inside each other.

This affects both Consumption and Standard SKUs, across new and historical runs. First reported April 27, 2026. The bug was introduced in v5.294 (not present in v5.273).

Root Cause

Regression introduced in PR #8875 (commit 3e71bcde8, March 4) which added code_interpreter built-in tool support. The commit added a shortcut in the v1 designer's MonitoringPanel that returned already-bound BoundParameters as raw inputs, creating an infinite feedback loop with useEffect(() => refetch(), [runMetaData]).

Fix (3 changes)

  1. Remove the shortcut -- always call getActionLinks() for fresh raw data
  2. Stable React Query key -- include actionTrackingId, startTime, endTime (matching v2 pattern)
  3. Remove the refetch loop -- remove useEffect(() => refetch(), [runMetaData])

Impact of Change

  • Users: Fixes infinite scrolling in run history for all Logic App types (Consumption + Standard).
  • Developers: No API changes. Internal data fetching pattern in v1 MonitoringPanel now matches v2.
  • System: Eliminates infinite refetch loop that caused unnecessary API calls and re-renders.

Test Plan

  • Unit tests added/updated
  • E2E tests added/updated
  • Manual testing completed
  • Tested in: Standalone designer with ARM token against live Standard Logic App

Test details:

  • monitoringTab.spec.tsx -- 6 unit tests all passing on hotfix branch
  • Regression test should not re-feed already-bound BoundParameters as raw inputs verifies the exact bug is fixed
  • Clean cherry-pick, no conflicts

Contributors

Screenshots/Videos

Before (Bug) - Infinite recursive nesting

Values in the monitoring panel display as infinitely nested {displayName, value} objects, continuously scrolling:

Before - Bug

After (Fix) - Clean value display

Values display correctly as flat, readable content:

After - Fix

@takyyon
fix(designer): Fix infinite recursive nesting in monitoring run histo…
70e43ce 
…ry values

The code_interpreter built-in tool support (3e71bcd, PR #8875) introduced
a shortcut that returned already-bound BoundParameters as raw inputs when
runMetaData.inputs existed. Combined with a refetch() triggered on every
runMetaData change, this created an infinite loop:

1. Raw inputs fetched → bound to {displayName, value} → stored on runData
2. runData change → refetch → shortcut returns already-bound data as 'raw'
3. Re-binding wraps {displayName, value} inside another {displayName, value}
4. Repeat infinitely → values scroll endlessly in the action boxes

Fix:
- Always call getActionLinks() for fresh raw data (never short-circuit)
- Use stable query key (actionTrackingId, startTime, endTime) so React Query
  caches properly and doesn't refetch when bound data changes
- Remove refetch() on runMetaData change that drove the infinite loop
- Use placeholderData instead of initialData to prevent premature dispatch

Affects both Consumption and Standard SKUs across all run history views.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 29, 2026 •
edited
Loading

🤖 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: fix(designer): Fix infinite recursive nesting in monitoring run history values [hotfix]
  • Issue: None significant — title is clear, follows conventional commit style and indicates scope + hotfix intent.
  • Recommendation: Keep as-is. Optionally you can drop [hotfix] if branch naming already conveys the hotfix, but this is stylistic.

✅ Commit Type

  • Properly selected (fix).
  • Only one box selected and it correctly reflects the change (bug fix).

⚠️ Risk Level

  • Assessment: The PR body marks Medium risk and the code changes are localized to the designer UI's MonitoringPanel and associated tests. Based on the diff (removing an infinite refetch loop, changing query key, and altering data-fetch behavior for monitoring inputs/outputs), the practical risk is Medium — the change affects how runtime data is fetched/displayed across runs and SKUs, but the scope is limited to the MonitoringPanel code path and includes unit tests.
  • Issue: The repository labels for this PR do not include a risk label (e.g., risk:low, risk:medium, risk:high). The PR body indicates Medium, but there is no matching risk:medium label on the PR.
  • Recommendation: Please add the risk:medium label to the PR so the label state matches the PR body. If you believe the change is Low or High, update both the PR body selection and the GitHub label accordingly.

✅ What & Why

  • Current: The PR body contains a detailed "What & Why" including problem, root cause, and a clear 3-point fix description.
  • Issue: None — the description is well-written and concise.
  • Recommendation: None (good job). If you want, add a single-sentence summary at the top for fast scanning (e.g., "Fix infinite recursive nesting in monitoring run history by always fetching raw action links and stabilizing the query key").

✅ Impact of Change

  • The Impact section is present and clearly separates Users / Developers / System impact.
  • Recommendation: None required. This is good.

✅ Test Plan

  • Assessment: The PR body claims unit tests were added/updated and manual testing was completed. The code diff includes updates to monitoringTab.spec.tsx and new/modified unit tests that exercise the changed behavior, which validates the claim.
  • Issue: E2E tests are not added; the PR marks E2E unchecked. That's acceptable given the unit tests + manual testing. If you have E2E coverage or a reason to omit it (e.g., too difficult to replicate runtime environment), add a short justification in the Test Plan.
  • Recommendation: If feasible, consider adding an E2E regression test later to cover a full run history scenario, but not required to merge now given the unit coverage and manual verification.

✅ Contributors

  • The PR lists contributors (at least @takyyon). Good.
  • Recommendation: Remember to credit any PMs/designers if they contributed to the fix or acceptance criteria (optional).

✅ Screenshots/Videos

  • Visuals included for before/after. Good for reviewers and release notes.
  • Recommendation: None.

Summary Table

Section Status Recommendation
Title ✅ Keep as-is (clear + conventional commit style)
Commit Type ✅ Correct (fix)
Risk Level ⚠️ Add risk:medium label to match PR body
What & Why ✅ Good, detailed
Impact of Change ✅ Good, clear
Test Plan ✅ Unit tests present. Consider E2E in future if needed
Contributors ✅ Good
Screenshots/Videos ✅ Good

Final Message
Please add the risk:medium GitHub label to this PR so the label state matches the PR body selection. Everything else in the PR title and body looks complete, well-documented, and supported by unit tests and manual validation. After adding the risk label (and removing needs-pr-update if that label is no longer applicable), this PR should be good to proceed.

Thank you for the clear description and tests — this made review straightforward.

Last updated: Wed, 29 Apr 2026 17:55:53 GMT

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 29, 2026 •
edited
Loading

📊 Coverage Check

🎉 All changed files have adequate test coverage!

@takyyon
Copy link
Copy Markdown
Contributor Author

takyyon commented Apr 29, 2026

Closing in favor of new PR with updated branch (review feedback addressed).

@takyyon takyyon closed this Apr 29, 2026
@takyyon takyyon reopened this Apr 29, 2026
@takyyon takyyon closed this Apr 29, 2026
@github-actions github-actions Bot mentioned this pull request May 6, 2026
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

pr-validated

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@takyyon