Significant-Gravitas/AutoGPT · error · DatabaseError
Failed to create store listing version
Error message
Failed to create store listing version
What it means
DatabaseError raised when the StoreListingVersion create() inside the submission transaction returns None. Prisma's create returning None (rather than raising) happens when the write is affected by the surrounding transaction state or the client cannot confirm the row; combined with the UniqueViolationError handler below, this is the 'create did not produce a row for an unexpected reason' branch of create_store_submission.
Source
Thrown at autogpt_platform/backend/backend/api/features/store/db.py:1001
# scalar: this nested create uses checked
# (relation) input syntax, and Prisma
# rejects the whole create when a raw FK
# field is mixed in ("Field does not exist
# in enclosing type").
**(
{"OwningOrg": {"connect": {"id": organization_id}}}
if organization_id
else {}
),
},
}
},
},
include={"StoreListing": True},
)
if not new_submission:
raise DatabaseError("Failed to create store listing version")
logger.debug(f"Created store listing for agent {graph_id}")
return store_model.StoreSubmission.from_listing_version(new_submission)
except prisma.errors.UniqueViolationError as exc:
# Attempt to check if the error was due to the slug field being unique
error_str = str(exc)
if "slug" in error_str.lower():
logger.debug(f"Slug '{slug}' is already in use by graph #{graph_id}")
raise store_exceptions.SlugAlreadyInUseError(
f"The slug '{slug}' is already in use by another one of your agents. "
"Please choose a different slug."
) from exc
else:
# Reraise as a generic database error for other unique violations
raise DatabaseError(
f"Unique constraint violated (not slug): {error_str}"
) from exc
except (View on GitHub (pinned to 9c8bb5550f)
Solutions
- Check server logs for the surrounding PrismaError — the None return usually accompanies an aborted transaction.
- Debounce/disable the publish button while a submission is in flight to prevent concurrent duplicates.
- If persistent, reproduce with logging around the create call and verify the transaction helper's isolation/timeout settings.
Example fix
// before
<button onClick={() => publish()}>Publish</button>
// after
const [busy, setBusy] = useState(false);
<button disabled={busy} onClick={() => { setBusy(true); publish().finally(() => setBusy(false)); }}>Publish</button>; Defensive patterns
Strategy: try-catch
Try / catch
from backend.util.exceptions import DatabaseError
try:
sub = await store_db.create_store_submission(...)
except DatabaseError as e:
if 'Failed to create store listing version' in str(e):
existing = await get_existing_submission(graph_id) # did it commit anyway?
if existing: return existing
raise Prevention
- Prevent concurrent duplicate submissions in the UI (in-flight lock on publish).
- After any ambiguous submission failure, check whether the listing was actually created before retrying.
- Keep transaction scope short to reduce abort windows.
When it happens
Trigger: The transaction context (async with transaction() as tx) aborts or the create is rolled back by a nested await failure; race where two submissions for the same agent interleave and one transaction is invalidated; prisma client version returning None on conflict inside interactive transactions.
Common situations: Double-click on Publish firing two concurrent submissions; retry logic racing the original request; interactive-transaction timeouts under slow DB load.
Related errors
- Unique constraint violated (not slug): {error_str}
- Failed to update store listing version
- Failed to create store submission
- Failed to edit store submission
- Failed to update profile
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/f4128c603c5173e9.
Report an issue: GitHub.