Call from a flow to another flow yields 502 no response

[NMBU2]

Hello, 

We have a flow that does calls to other flows, as an effort to try and reduce the complexity/scope in the main "request handler" flow that is triggered by a Forms submit. We have several HTTP steps in the main flow that calls other flows, which starts with When an HTTP request is received.

Usually this works fine, but today as I was testing during development I got this 502 "no response" error when calling this URL from an HTTP step: 

https://prod-80.westeurope.logic.azure.com:443/workflows/dc85... (the URL has been truncated)

To my understanding, the main flow is possibly not running on prod-80.westeurope.logic.azure.com, but could in fact be running on any other *.weseurope.logic.azure.com host? I don't know if this is relevant but I need our cloud solution to be stable and help to figure this out. I'd rather not merge the flows as some are reused in branches and I don't think duplicating too much will be a good way to maintain the "code". 

To my question:

Are there any best practices for doing this flow-to-flow http calls? As I don't seem to be able to control the host manually (nor should I probably), I need a way to ensure our cloud solution is as stable as possible.

I suppose for now all I can do is to add error handling to the HTTP step, so if it fails the admin is alerted and can handle this manually. But it's not optimal since this requires admin's attention and will clutter the flow further. The flow is not designed for resubmitting if it fails half way through like it did in this case.

Any advise is much appreciated.

Here's the raw output:

{
    "statusCode": 502,
    "headers": {
        "Pragma": "no-cache",
        "x-ms-failure-cause": "Trigger",
        "x-ms-workflow-run-id": "08585812199223026642852110080CU80",
        "x-ms-correlation-id": "037db9aa-d32c-480f-9428-91f9a9afb759",
        "x-ms-client-tracking-id": "08585812204012010017197326105CU127",
        "x-ms-trigger-history-name": "08585812199223026642852110080CU80",
        "x-ms-execution-location": "westeurope",
        "x-ms-workflow-system-id": "/locations/westeurope/scaleunits/prod-80/workflows/dc85a7a598de4d21af72c50cd1fac975",
        "x-ms-workflow-id": "dc85a7a598de4d21af72c50cd1fac975",
        "x-ms-workflow-version": "08585831183536757411",
        "x-ms-workflow-name": "804d7fc7-0b31-45a3-a163-e2aa5accc0e0",
        "x-ms-tracking-id": "037db9aa-d32c-480f-9428-91f9a9afb759",
        "x-ms-ratelimit-burst-remaining-workflow-writes": "2499",
        "x-ms-ratelimit-remaining-workflow-download-contentsize": "178956288",
        "x-ms-ratelimit-remaining-workflow-upload-contentsize": "178956176",
        "x-ms-ratelimit-time-remaining-directapirequests": "16664552",
        "x-ms-request-id": "westeurope:037db9aa-d32c-480f-9428-91f9a9afb759",
        "Strict-Transport-Security": "max-age=31536000; includeSubDomains",
        "Connection": "close",
        "Cache-Control": "no-cache",
        "Date": "Fri, 07 May 2021 11:29:25 GMT",
        "Content-Length": "163",
        "Content-Type": "application/json; charset=utf-8",
        "Expires": "-1"
    },
    "body": {
        "error": {
            "code": "NoResponse",
            "message": "The server did not receive a response from an upstream server. Request tracking id '08585812199223026642852110080CU80'."
        }
    }
}

--

Anders Nordbø

Norwegian University of Life Sciences

[Pstork1 · Accepted solution]

If you build all your flows in a solution you can completely avoid having to use HTTP calls to call child flows.  Using HTTP is the old method to chain flows together.  The current preferred method is to use the Run a Child flow action.

The child flow is then triggered using a manual trigger where you've specified the Inputs you want the flow to receive.

This is a much easier and more stable setup than the HTTP call/HTTP received configuration you are using.  The one requirement is that both the parent and child flows need to be in the same solution.

[NMBU2]

Thank you @Pstork1 , that looks like what I want 🙂

BTW in case someone stumbles upon this the solution was to go see what was wrong in the flow I made the call to. As it turns out, it had failed and was not returning a response to the caller. The step that failed aborted the flow, so the step "Respond to a PowerApp of Flow" was not called. If allowing the flow to continue even if it fails is an option, you may get better error handling in the flow that calls (not 502), by defining "configure run after" on the menu for the step that is prone to fail.

[Anonymous]

Thanks for the note for posterity @NMBU2  - exactly what I needed!