When action level resubmit is unavailable provide a reason in the UI

[asos-martinsmith]

Priority

P3 - Medium (Nice to have)

Feature Area

Monitoring/Run History

Problem Statement

I previously raised #8968 reporting that the "Submit from this action" button was not appearing in run history in certain workflows.

It was stated there that this button only appears if canResubmit is reported as true by the API.

It is confusing to the end user why this is sometimes available and sometimes not and what actions we need to take to get this functionality restored.

Proposed Solution

It seems there are multiple scenarios that can block this functionality. These should be documented.

If canresubmit : false was found on an action that was Succeeded, Failed, or TimedOut it would be useful to provide a link to that documentation.

In a perfect world this would also advise the specific blocker case causing the functionality not to be available.

Copilot came up with the following possible reasons for me but I don't know if this is entirely comprehensive/accurate

Complete list of blockers

The runtime returns canResubmit: false for an action if any of the following is true:

Blocker 1 — Host kill‑switch

The host setting Microsoft.Azure.Workflows.IsResubmitActionsEnabled is false (default: true).

Scope: All actions in all workflows on the host.

Blocker 2 — Action not in definition

The action exists in run history but not in the current workflow definition (e.g. the definition was modified after the run).

Scope: That specific action.

Blocker 3 — Repeating action types

The action itself is a Foreach, Until, or Agent (i.e. IsRepeating() == true).

Scope: That specific action.

Blocker 4 — Upstream repeating action

Any action earlier in the run's execution order is a Foreach, Until, or Agent. Everything downstream of a loop/agent becomes non‑resubmittable.

Scope: All actions after the first repeating action.

Blocker 5 — Non‑terminal action status

The action is in a non‑terminal state: Running, Waiting, Skipped, Cancelled, Aborted, etc. Only Succeeded, Failed, and TimedOut pass the IsActionExecuted() check.

Scope: That specific action.

Blocker 6 — Workflow graph has no Hamiltonian path (non‑linear graph)

This is the most common hidden blocker and the hardest to diagnose. If the full sequencer graph (which includes flattened scope internals, not just top‑level actions) contains any fork (two or more nodes that depend on the same predecessor), the HasHamiltonianPath check fails, causing ResubmitSequencerType = Distributed, which makes isLinear = false, which forces canResubmit = false for every action in the entire run.

The runtime flattens all nested actions via FlattenNestedActions() and decomposes scope‑typed actions (Scope, If, Foreach, Until, Switch) into BeginScope/EndScope pairs. Child actions are wired between these pairs via PopulateParentDependencies. This means parallel children inside a scope create a fork at the BeginScope node — wrapping parallel branches in a scope does not help.

Common patterns that trigger this:

Pattern	Example	Why it breaks
Parallel branches	A → B, A → C	B and C both depend on A; in any ordering one won't directly follow the other
Scope + error handler at same level	Scope → Delete (SUCCEEDED), Scope → ExceptionHandler (FAILED)	Two actions list the same scope in their RunAfter
Fan‑out/fan‑in	A → B, A → C, then D depends on both B and C	Fork at A breaks the path

Scope: All actions in the entire run — even the very first action gets canResubmit: false.

Key insight: The runtime doesn't care that the fork arms fire on different conditions (SUCCEEDED vs FAILED). The RunAfter graph is analysed structurally, not by condition. Two actions depending on the same predecessor = fork = no Hamiltonian path.

Alternatives Considered

No response

Which Logic App type(s) should this apply to?

Standard

Additional context

No response