Connections Hub: Redirect workflow action does not navigate the browser when launched from a Connection Request

[randyjreed]

Description

The new Obsidian "Connections Hub" block (Rock.Blocks/Engagement/ConnectionsHub.cs) lets you manually launch a Connection Workflow against a Connection Request. If that workflow performs a "Redirect to Page" action (Rock.Workflow.Action.Redirect) to send the user to another page or workflow, the redirect silently never happens. The UI shows a message saying the workflow was launched, but the browser never navigates anywhere. This specifically affects workflows that use a Redirect action (e.g. a workflow that activates a second workflow and then redirects the requester to fill it out), not workflows that stop at a plain entry Form, which redirect correctly.

The classic WebForms "Connection Request Board" block does not have this problem. A Redirect action fired from a workflow launched there redirects the browser correctly.

Suspected Root Cause (confirmed against source)

Rock/Workflow/Action/WorkflowControl/Redirect.cs explicitly detects whether it is running inside an Obsidian block action call, and if so, refuses to redirect at all:

public override bool Execute( RockContext rockContext, WorkflowAction action, object entity, out List<string> errorMessages )
{
    errorMessages = new List<string>();
 
    if ( IsObsidianBlock() )
    {
        return false;
    }
 
    string url = GetAttributeValue( action, AttributeKey.Url );
    ...
    bool canSendRedirect = !string.IsNullOrWhiteSpace( url ) && HttpContext.Current != null;
 
    if ( canSendRedirect )
    {
        HttpContext.Current.Response.Redirect( url, false );
    }
    ...
}
 
private bool IsObsidianBlock()
{
    // If we are being processed by the new Obsidian Workflow Entry
    // block, then don't continue processing this action as it will be
    // handled by the block. ...
    if ( RockRequestContextAccessor.Current?.RequestUri?.AbsolutePath?.StartsWith( "/api/v2/BlockActions", StringComparison.OrdinalIgnoreCase ) == true )
    {
        return true;
    }
    ...
}

When Connections Hub launches a workflow, it does so from inside a /api/v2/BlockActions/... call. IsObsidianBlock() sees that request path, returns true, and Execute() bails out with return false before ever calling HttpContext.Current.Response.Redirect(...). No error is raised; the action just quietly does nothing. The classic board launches the workflow from a normal WebForms postback (a page URL, not /api/v2/BlockActions), so IsObsidianBlock() returns false there and the same code goes on to call Response.Redirect(url, false), which works because it's a real page postback, not an AJAX call.

Rock does have a newer mechanism built for exactly this situation: Redirect also implements IInteractiveAction.StartAction, which returns an InteractiveActionResult containing a InteractiveMessageBag of type Redirect with the target URL, meant for Obsidian UIs to consume and navigate on. That interface is used by Rock's own Obsidian "Workflow Entry" block. Connections Hub's manual "Launch Workflow" action does not appear to call into this mechanism, so a Redirect action launched from Connections Hub has no path to reach the browser at all: the old Response.Redirect route is explicitly disabled for Obsidian block actions, and the new IInteractiveAction route isn't wired up for this launch surface.

This also explains why a plain sample workflow that simply stops at a Form action works fine when tested on the demo site: those rely on Connections Hub's HasActiveEntryForm check and its own "open the workflow entry page" logic, a separate mechanism from the Redirect action. The bug is specific to workflows that use a Redirect action to send the user somewhere (including the common pattern of launching a second workflow and redirecting to it).

I have not found an existing open issue against Connections Hub for this. There is a related, older issue (#5896) about inconsistent workflow-launch behavior between Connection Requests and the Person Profile action menu, but that is about a different mechanism (a workflow being reprocessed a second time on redirect) and predates Connections Hub.

Actual Behavior

Launching a manual Connection Workflow from Connections Hub that includes a "Redirect to Page" action shows a message saying the workflow was launched, but the browser never navigates to the redirect target. This reproduces with a minimal workflow (attached: "Redirect from Connection Request") that just pulls the Connection Request and requester, then redirects, no second workflow involved, and with IsPersisted set to true (ruling out the separate "not persisted" re-run issue described in #5896). A simple workflow that only stops at a Form action (no Redirect action) does not show this problem; it correctly opens the entry page.

Expected Behavior

When a manually launched workflow performs a Redirect action, Connections Hub should navigate the browser to that URL, consistent with the classic Connection Request Board block.

Steps to Reproduce

1. Import the attached workflow, "Redirect from Connection Request." It is a persisted workflow whose only notable action is a "Redirect to Page" action (Rock.Workflow.Action.Redirect) pointed at a test URL.
2. Add it as a manual workflow on a Connection Opportunity / Connection Type.
3. Open the Connections Hub block for that connection type.
4. Select a Connection Request and use "Launch Workflow" to launch the workflow above.
5. Observe: a message appears saying the workflow was launched, but the browser never navigates anywhere.
6. For comparison, do the same from the classic Connection Request Board block: the Redirect action correctly navigates the browser.
7. For further comparison, launch a workflow that only stops at a Form action (no Redirect action) from Connections Hub: this works correctly and opens the entry page.

Redirect from Connection Request_202607150732.json

Issue Confirmation

• Perform a search on the Github Issues to see if your bug is already reported.
• Reproduced the problem on a fresh install or on the demo site.

Rock Version

19.1.8 (confirmed present in this version; also present on develop)

Client Culture Setting

en-US