mastra-ai/mastra · error · HTTPException

Failed to resolve created prompt block

Error message

Failed to resolve created prompt block

What it means

After creating a prompt block, the handler re-reads it via `promptBlockStore.getByIdResolved(id, { status: 'draft' })` to return the resolved view (thin record + version config). If the resolved lookup returns null immediately after a successful create, the store's resolution logic is inconsistent with creation, and the server throws this 500 error. This indicates an internal storage/versioning defect rather than a caller mistake.

Source

Thrown at packages/server/src/server/handlers/stored-prompt-blocks.ts:207

      await promptBlockStore.create({
        promptBlock: {
          id,
          authorId,
          metadata: scopeStoredResourceMetadata(metadata, await getStoredResourceScope(mastra, requestContext)),
          name,
          description,
          content,
          rules,
          requestContextSchema,
        },
      });

      // Return the resolved prompt block (thin record + version config)
      // Use draft status since newly created entities start as drafts
      const resolved = await promptBlockStore.getByIdResolved(id, { status: 'draft' });
      if (!resolved) {
        throw new HTTPException(500, { message: 'Failed to resolve created prompt block' });
      }

      const latestVersion = await promptBlockStore.getLatestVersion(id);
      const hasDraft = !!(
        latestVersion &&
        (!resolved.activeVersionId || latestVersion.id !== resolved.activeVersionId)
      );

      return { ...resolved, hasDraft };
    } catch (error) {
      return handleError(error, 'Error creating stored prompt block');
    }
  },
});

/**
 * PATCH /stored/prompt-blocks/:storedPromptBlockId - Update a stored prompt block
 */

View on GitHub (pinned to 75dd419e61)

Solutions

  1. Upgrade @mastra/core and the storage package so create and getByIdResolved are consistent
  2. Check server logs/database to confirm the prompt block row (and its draft version row) was actually written
  3. If using a custom storage adapter, implement getByIdResolved to resolve records created by create()
  4. As a workaround, verify the block exists via GET /stored/prompt-blocks/:id?status=draft after a 500 and retry only if it was not persisted
Defensive patterns

Strategy: retry

Try / catch

try {
  const created = await client.createStoredPromptBlock(body);
  return created;
} catch (e) {
  if (isHTTPException(e) && e.status === 500 && e.message === 'Failed to resolve created prompt block') {
    // verify persistence, then retry once; else report storage bug
    const check = await fetch(`${baseUrl}/api/stored/prompt-blocks/${body.id}?status=draft`);
    if (!check.ok) throw e;
    return check.json();
  }
  throw e;
}

Prevention

When it happens

Trigger: POST /stored/prompt-blocks where `create()` succeeded but `getByIdResolved(id, { status: 'draft' })` returns null — i.e. the store created the record but cannot resolve it with draft status immediately afterward.

Common situations: Storage adapters with eventually-consistent reads; partially implemented `getByIdResolved` in custom or newer storage backends; versioning records not written atomically with the base record during create; storage migration/version mismatch leaving the create path writing records the resolve path cannot read.

Related errors


AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/45687c70c086f83e. Report an issue: GitHub.