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
- Upgrade @mastra/core and the storage package so create and getByIdResolved are consistent
- Check server logs/database to confirm the prompt block row (and its draft version row) was actually written
- If using a custom storage adapter, implement getByIdResolved to resolve records created by create()
- 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
- Keep core and storage packages on matching versions
- If using a custom store, test create-then-resolve round trips
- Report persistent occurrences as a storage adapter bug with DB state
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
- AcpAgent does not support resuming suspended generate calls
- AcpAgent does not support resuming suspended stream calls
- ACP prompt stopped before completing: ${response.stopReason}
- ClaudeSDKAgent resumeData must include a message.
- DATASET_ITEM_NOT_FOUND
AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30).
Data as JSON: /api/errors/45687c70c086f83e.
Report an issue: GitHub.