fix(DesignerV2): Use ARM /run endpoint for published workflow triggers instead of listCallbackUrl

[rllyy97]

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

What & Why

Fixes #8870 - The V2 designer was using the listCallbackUrl endpoint to get a SAS-signed URL, then invoking the trigger directly via that URL (no ARM auth). This differs from V1, which POSTs directly to the /triggers/{triggerName}/run ARM endpoint with ARM authentication.

This changes the V2 FloatingRunButton to construct the ARM /run URL directly for published workflows, matching V1 behavior.

Impact of Change

• Users: Published workflow "Run" button in the V2 designer now uses the same ARM-authenticated /run endpoint as V1, improving reliability and consistency.
• Developers: WorkflowService().getCallbackUrl() is no longer called for published workflow runs in FloatingRunButton. The WorkflowService import was removed from this file.
• System: One fewer network call per run (no longer needs listCallbackUrl before invoking). Auth is now ARM-based instead of SAS token.

Test Plan

• Unit tests added/updated
• E2E tests added/updated
• Manual testing completed
• Tested in:

Manually tested, behavior matches V1 behavior now.

Contributors

@rllyy97

Screenshots/Videos

N/A

[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: fix(DesignerV2): Use ARM /run endpoint for published workflow triggers instead of listCallbackUrl
• Issue: None — title is clear, follows conventional commit style, and describes the change and motivation.
• Recommendation: None.

---

✅ Commit Type

• Properly selected (fix).
• Only one box selected in the PR body which is correct.

---

✅ Risk Level

• The PR body marks this as Low and the PR has the risk:low label. This matches the code changes and tests added/updated.

---

✅ What & Why

• Current: "Fixes [NewDesigner]:When identity is in off and run the workflow ,Run is getting error instead of run fail. #8870 - The V2 designer was using the listCallbackUrl endpoint ... This changes the V2 FloatingRunButton to construct the ARM /run URL directly for published workflows, matching V1 behavior."
• Issue: None — concise and explains both the problem and the rationale.
• Recommendation: None.

---

✅ Impact of Change

• The Impact section is present and correctly calls out Users, Developers, and System impacts.
• Recommendation: Consider adding one line calling out any consumers of WorkflowService().getCallbackUrl() elsewhere (if applicable) so reviewers can easily see other call sites that might be affected.
  • Users: Published workflow Run button in V2 now uses ARM /run endpoint — consistent and reliable.
  • Developers: FloatingRunButton no longer calls WorkflowService().getCallbackUrl() for published runs; WorkflowService import removed from this file.
  • System: One fewer network call per run; ARM auth instead of SAS.

---

✅ Test Plan

• Unit tests were added/updated in the diff for getPublishedRunUrl — this matches the PR's claim that unit tests were updated.
• E2E tests are not present and not selected in the body; manual testing is marked as completed and noted.
• Recommendation: Because this changes the invocation/authentication flow (SAS -> ARM /run), it's recommended to add at least one small integration or E2E test (or a brief note in the PR explaining why E2E/integration isn't necessary). This helps ensure end-to-end auth flows (ARM tokens) succeed in the environments where this runs.

---

✅ Contributors

• Contributors are listed (@rllyy97). Good.
• Recommendation: None.

---

✅ Screenshots/Videos

• Not applicable (behavioral change) and marked N/A in the PR body. That's fine.

---

Summary Table

Section	Status	Recommendation
Title	✅	None needed.
Commit Type	✅	None needed.
Risk Level	✅	None needed.
What & Why	✅	None needed.
Impact of Change	✅	Consider a short note about other call sites of WorkflowService if relevant.
Test Plan	✅	Add an integration/E2E test or explain why it's not needed due to environment/auth constraints.
Contributors	✅	None needed.
Screenshots/Videos	✅	N/A — correct for behavioral change.

---

Summary

• Overall: The PR title and body conform to the required template and are complete. The risk label matches the described risk and the code changes. Unit tests have been added that cover URL generation logic and the change in invocation. The change appears confined in scope and low risk.

Additional Suggestions / Minor Improvements

1. Add or document an integration/E2E test that validates the ARM-authenticated run call succeeds in an environment representative of production (auth token present). If adding E2E is not feasible, include a short explanation in the Test Plan detailing why manual testing is sufficient for this change.
2. Add a small unit test that covers edge cases for siteResourceId formatting (e.g., trailing slash, uppercase/lowercase resource provider strings) to avoid malformed paths in some hostnames/resourceId shapes.
3. Consider a short comment in the code or PR explaining why workflowName is intentionally not used in the consumption path (clarifies the design decision for future readers).
4. Search the codebase for other usages of WorkflowService().getCallbackUrl() that might expect SAS URLs and note any consumer updates if needed.

Please update only if you want to add the optional integration test or the suggested clarifying notes. Otherwise this PR looks good to merge. Thank you for the clear PR and tests!

---

Last updated: Wed, 08 Apr 2026 18:32:05 GMT

[github-actions]

📊 Coverage Check

No source files changed in this PR.