twentyhq/twenty · error · Error

failed to request artifact import for call recording ${callR

Error message

failed to request artifact import for call recording ${callRecordingId}

What it means

Inside the Recall webhook handler, after a matching `CallRecording` is found, `requestCallRecordingArtifactsImportOrThrow` dispatches a logic-function call (`requestCallRecordingArtifactsImport`) to queue media/artifact import for that recording. That dispatcher returns a truthy/falsy result; if it returns falsy the handler throws, which surfaces as a non-2xx to Svix so the webhook is retried. The error therefore signals a dispatch/queue failure, not a media download failure.

Source

Thrown at packages/twenty-apps/public/call-recorder/src/logic-functions/flows/handle-recall-webhook.util.ts:200

  return {
    status: 'queued',
    event: webhookEvent.event,
    callRecordingId: callRecording.id,
  };
};

const requestCallRecordingArtifactsImportOrThrow = async ({
  callRecordingId,
}: {
  callRecordingId: string;
}): Promise<void> => {
  const importRequested = await requestCallRecordingArtifactsImport({
    callRecordingId,
    requestedAt: new Date().toISOString(),
  });

  if (!importRequested) {
    throw new Error(
      `failed to request artifact import for call recording ${callRecordingId}`,
    );
  }
};

const findMatchingCallRecording = async ({
  client,
  webhookEvent,
}: {
  client: CoreApiClient;
  webhookEvent: RecallWebhookEvent;
}): Promise<CallRecordingRecord | undefined> => {
  if (!isUndefined(webhookEvent.callRecordingIdFromMetadata)) {
    return (
      await findCallRecordingsByFilter(client, {
        id: { eq: webhookEvent.callRecordingIdFromMetadata },
      })
    )[0];

View on GitHub (pinned to 1f5dd2bbd2)

Solutions

Confirm the target logic function invoked by `requestCallRecordingArtifactsImport` is published and its universal identifier matches the dispatch.
Inspect logs around the dispatch call for the underlying reason it returned falsy (the dispatcher should log before returning false).
Verify the `callRecordingId` is in a state that accepts an import request (not already terminal/importing).
Because a throw triggers Svix retry, a transient platform error often resolves on the next retry — check whether the recording eventually imports before chasing a code fix.

Example fix

// before
const importRequested = await requestCallRecordingArtifactsImport({
  callRecordingId,
  requestedAt: new Date().toISOString(),
});
if (!importRequested) {
  throw new Error(`failed to request artifact import for call recording ${callRecordingId}`);
}

// after — capture and propagate the dispatcher's failure reason
const importResult = await requestCallRecordingArtifactsImport({
  callRecordingId,
  requestedAt: new Date().toISOString(),
});
if (!importResult?.ok) {
  throw new Error(
    `failed to request artifact import for call recording ${callRecordingId}: ${importResult?.error ?? 'dispatcher returned falsy'}`,
  );
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: confirm the target logic function is published before dispatching.
const published = await isLogicFunctionPublished(ARTIFACT_IMPORT_LF_IDENTIFIER);
if (!published) {
  throw new Error(`Artifact-import logic function ${ARTIFACT_IMPORT_LF_IDENTIFIER} is not published`);
}

Try / catch

try {
  await requestCallRecordingArtifactsImportOrThrow({ callRecordingId });
} catch (error) {
  // A throw becomes a non-2xx → Svix retries. Log the failure id for correlation
  // but allow the throw to propagate so the webhook is retried.
  console.error(`[call-recorder] artifact-import dispatch failed for ${callRecordingId}: ${error instanceof Error ? error.message : String(error)}`);
  throw error;
}

Prevention

Publish the artifact-import logic function in every environment before enabling the webhook route.
Make the dispatcher return a structured result (ok/error) instead of a bare boolean so failures are diagnosable.
Treat a thrown error here as a retry signal (Svix) rather than a permanent failure.
Log the callRecordingId and dispatch target identifier on every attempt for correlation.

When it happens

Trigger: The dispatch target logic function is misconfigured/unpublished, the CallRecording id passed to the dispatcher does not resolve, the dispatcher hits a transient platform error and returns `false`, or the call recording is in a state that refuses a new import request (e.g. already importing/terminal).

Common situations: A new deployment where the artifact-import logic function was not published or its universal identifier changed; a Recall webhook arriving for a recording that was concurrently marked failed/deleted; a platform-level throttle that makes the dispatch return falsy.

Related errors

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