Documentation

OpenWhisk sequence HTTP 504 and 502 errors in Adobe App Builder

Last update: Wed Apr 08 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

In Adobe App Builder, applications that use OpenWhisk sequences encounter HTTP 504 or HTTP 502 errors during action execution when actions depend on external services. These errors occur when an external API does not respond within the OpenWhisk runtime timeout window or when the runtime environment cannot resolve a hostname due to DNS configuration issues. In these scenarios, downstream actions in the sequence also fail when they attempt to process an undefined response from an earlier step. To fix this, identify the failing dependency, validate DNS resolution, configure shorter client-side timeouts, and add defensive error handling in sequence actions.

Description description

Environment

  • Product: Adobe App Builder
  • Runtime: Adobe I/O Runtime (OpenWhisk)
  • Trigger source: Adobe I/O Events or event-driven integrations

Typical runtime constraints:

Component
Timeout
I/O Events delivery timeout
60 seconds
OpenWhisk action timeout
60 seconds
Sequence execution timeout
60 seconds

These limits apply when actions execute synchronously within a sequence.

Issue/Symptoms

Symptom 1 – HTTP 504 Gateway Timeout from OpenWhisk controller

When an action exceeds the runtime limit, the OpenWhisk controller returns an HTTP 504 error.

Example activation log pattern:

sequence execution failed OpenWhiskError:
POST https://controller-gw.../actions/<sequence-name>
Returned HTTP 504 (Gateway Timeout)Error:
"The action exceeded its time limits of 60000 milliseconds"

This means the action ran until the maximum runtime limit without completing successfully.

Typical cause:
An outbound API request from the action waits indefinitely for a response.

Symptom 2 – HTTP 502 with application error

When an action fails internally before reaching the runtime timeout, OpenWhisk returns an HTTP 502 response with an application-level error.

Example log:

sequence execution failed OpenWhiskError:
Returned HTTP 502 (Bad Gateway) --> "application error, status code: 500"

This means the action encountered an error during execution and returned a failure status.

Symptom 3 – DNS resolution failure for outbound API requests

When an action calls an external hostname that cannot be resolved, logs show DNS-related errors.

Example error pattern:

Error: getaddrinfo ENOTFOUND api.example.com

This means the runtime environment cannot resolve the hostname used by the action for outbound requests.

Symptom 4 – Downstream TypeError in sequence handler

When a preceding action fails or times out, downstream sequence steps attempt to process an undefined response.

Example runtime error:

TypeError: Cannot read properties of undefined (reading 'result')

This happens when sequence handlers assume a valid response from a previous step that failed.

Cause

Two common root causes lead to these errors.

1. External API latency or unresponsiveness
When an OpenWhisk action calls an external service that does not respond within the configured runtime window, the action continues waiting until the OpenWhisk timeout is reached.
After the timeout is exceeded, the runtime terminates the action and the controller returns an HTTP 504 error.

2. DNS resolution failures for outbound requests
When the hostname used by the action cannot be resolved through DNS, the outbound request fails immediately.
The action then returns an application error, often HTTP 500, which OpenWhisk surfaces to the caller as an HTTP 502 error.

Both issues come from application-level dependencies and not from platform infrastructure problems.

Resolution resolution

To fix the issue, follow these steps:

  1. Verify external API availability

    Confirm that the external API endpoint called by the OpenWhisk action is accessible and responding normally.

    Test the endpoint with a direct request:

    code language-none 
    curl https://api.example.com/endpoint

    Expected result:

    1. The request returns a valid HTTP response.
    2. The response time stays within acceptable limits, typically a few seconds.

    If the request hangs or takes too long:

    1. Verify that the external service is operational.
    2. Confirm that the endpoint URL is correct.
    3. Check firewall or network restrictions affecting outbound traffic.
    4. Contact the API provider if the service appears degraded.

  2. Implement shorter HTTP client timeouts

    External calls from OpenWhisk actions must use a client-side timeout that is shorter than the platform’s runtime limit.

    This prevents the action from waiting until the full 60-second runtime timeout.

    Example implementation using a Node.js HTTP client:

    code language-none 
    const axios = require("axios")

await axios.get("https://api.example.com/endpoint",
  { timeout: 8000 }
)

    Recommended practice:

    1. Configure outbound HTTP timeouts between 5 and 10 seconds.
    2. Handle timeout exceptions explicitly in the action logic.

    This ensures the action fails fast instead of consuming the full runtime window.

  3. Validate DNS configuration

    If logs show ENOTFOUND errors, verify that the hostname used by the action resolves correctly.

    Use DNS lookup tools such as:

    code language-none 
    nslookup api.example.com

    or

    code language-none 
    dig api.example.com

    Expected result:

    The command returns an IP address for the hostname.

    code language-none 
    Name: api.example.com
Address: <IP address>

    If no IP address is returned:

    1. Confirm that the hostname is correct.
    2. Verify that the DNS record exists.
    3. Check DNS propagation status.
    4. Ensure no internal DNS restrictions block resolution.

  4. Add defensive error handling in action sequences

    Update sequence handlers to handle upstream failures and avoid assuming that previous actions returned valid responses.

    Example safeguard:

    code language-none 
    if (!response || !response.result) {
  return
  { error: "Upstream action failed or timed out" }
}

    This prevents downstream runtime errors when earlier sequence steps fail.

Verification

After applying the recommended changes, verify that the issue no longer occurs.

  1. Trigger the App Builder action or event again.

  2. Open the App Builder Console and review the activation logs.

  3. Confirm the following results:

    • No HTTP 504 errors appear.
    • No HTTP 502 application errors occur.
    • External API requests complete within the configured timeout.
    • Sequence handlers return valid responses.

A successful activation shows a status similar to the following:

status: success
duration: < expected runtime

The total execution time should remain well below the 60-second runtime limit.

Additional considerations

Platform behavior

The OpenWhisk runtime enforces a hard execution limit for actions that run within sequences. When an action reaches this limit, the runtime terminates the action automatically.
An HTTP 504 response from the controller confirms that the runtime limit was reached.

Managed event handlers

Some Adobe App Builder workflows invoke Adobe-managed actions, such as event handlers for Adobe I/O Events. These actions run as part of the sequence but are maintained by Adobe and do not require modification.

Monitoring recommendations

To reduce the risk of similar issues:

  1. Monitor external API latency.
  2. Implement retries with exponential backoff.
  3. Log outbound API request durations.
  4. Track action execution times in activation logs.

These practices help identify external dependencies that cause runtime delays.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f