twentyhq/twenty · error · Error

isString(response.error) ? response.error : JSON.stringify(r

Error message

isString(response.error) ? response.error : JSON.stringify(response.error)

What it means

The message shown is the literal expression thrown at useTestHttpRequest.ts:127: the testHttpRequest mutation returned `success: false` and this Error's message is the server's `error` payload (stringified if it is not already a string). It represents a real failure of the outbound HTTP call the workflow step was testing.

Source

Thrown at packages/twenty-front/src/modules/workflow/workflow-steps/workflow-actions/http-request-action/hooks/useTestHttpRequest.ts:127

        const resultData = isString(response.result)
          ? response.result
          : JSON.stringify(response.result, null, 2);
        const language = isObject(response.result) ? 'json' : 'plaintext';

        setHttpRequestTestData((prev) => ({
          ...prev,
          output: {
            data: resultData,
            status: response.status ?? 200,
            statusText: response.statusText ?? 'OK',
            headers: response.headers ?? {},
            duration,
            error: undefined,
          },
          language,
        }));
      } else {
        throw new Error(
          isString(response.error)
            ? response.error
            : JSON.stringify(response.error),
        );
      }
    } catch (error) {
      const duration = Date.now() - startTime;

      const rawErrorMessage =
        error instanceof Error ? error.message : t`HTTP request failed`;

      const jsonParsedErrorMessage = parseJson(rawErrorMessage);

      const errorMessage = isDefined(jsonParsedErrorMessage)
        ? JSON.stringify(jsonParsedErrorMessage, null, 2)
        : rawErrorMessage;

      const language = isDefined(jsonParsedErrorMessage) ? 'json' : 'plaintext';

View on GitHub (pinned to 1f5dd2bbd2)

Solutions

  1. Read the thrown message: for non-string errors it is JSON-stringified, so parse it to find status/url/detail.
  2. Re-run the same URL/headers/body with curl from the server's network to reproduce the upstream failure.
  3. Correct the URL, add the missing Authorization header, or fix the body template so substituted output is valid.

Example fix

// the thrown message is the upstream error; surface it to the user
// before: throw new Error(isString(response.error) ? response.error : JSON.stringify(response.error));
// after:  const upstream = isString(response.error) ? response.error : JSON.stringify(response.error, null, 2);
//         throw new Error(`HTTP request failed: ${upstream}`);
Defensive patterns

Strategy: try-catch

Validate before calling

const assertUpstreamSuccess = (resp: { success: boolean; error?: unknown }) => {
  if (resp.success !== true) {
    throw new Error(isString(resp.error) ? resp.error : JSON.stringify(resp.error));
  }
};

Type guard

const isHttpTestSuccess = (r: unknown): r is { success: true; result: unknown } =>
  typeof r === 'object' && r !== null && (r as any).success === true;

Try / catch

// the hook already catches and surfaces errorMessage via httpRequestTestData.
// Consume that state rather than re-throwing:
if (httpRequestTestData.output?.error) {
  showTestError(httpRequestTestData.output.error);
}

Prevention

When it happens

Trigger: The target URL of the workflow HTTP request action is unreachable, returns a non-2xx status, has invalid/TLS problems, or rejects the request (auth, headers, body). The server wraps that upstream failure into `response.error` and the client re-throws it.

Common situations: Testing a workflow HTTP step against a URL that is down, requires authentication not supplied, blocks the server's egress IP, has an invalid/expired TLS cert, or returns 4xx/5xx. Body template substitution produced invalid JSON.

Related errors


AI-assisted analysis of twentyhq/twenty@1f5dd2bbd2 (2026-08-12). Data as JSON: /api/errors/3d6c97ba5b00facb. Report an issue: GitHub.