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
- Read the thrown message: for non-string errors it is JSON-stringified, so parse it to find status/url/detail.
- Re-run the same URL/headers/body with curl from the server's network to reproduce the upstream failure.
- 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
- Before testing, run the same URL/headers/body from the server network with curl to isolate egress issues.
- Validate substituted URL is a well-formed absolute URL and body (when JSON) parses.
- Make sure authorization headers are populated when the target requires auth.
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
- No response from server
- OPERATION_FAILED
- ${res.statusText}: ${await res.text()}
- ${response.statusText}: ${response.rawBody}
- Invalid JSON response
AI-assisted analysis of twentyhq/twenty@1f5dd2bbd2 (2026-08-12).
Data as JSON: /api/errors/3d6c97ba5b00facb.
Report an issue: GitHub.