fix(backend): credential issuance fails against a clean install (Draft & Publish id drift)

[arqueon]

Summary

POST /api/credentials/issue -- the flow documented in this repo's own README -- fails on a fresh database with either:

"Error creating status list credential: Issuer not found"

or, further along the same request:

"1 relation(s) of type api::revocation-list.revocation-list associated with this entity do not exist"

This isn't a config/environment problem -- it reproduces against a clean install with a correctly created and published issuer profile and achievement.

Root cause

Confirmed empirically with strapi console against a real Postgres instance (not just by reading the code). revocation-list has draftAndPublish: true. In Strapi 5, entityService.update() on an already-published Draft & Publish entity does not update that row in place -- it deletes it and creates a new draft/published pair (same documentId, different numeric id):

const upd = await strapi.entityService.update(
  'api::revocation-list.revocation-list', 6, { data: { nextIndex: 1 } }
)
// upd.id === 7, not 6 -- row 6 no longer exists in the database

assignNextIndex() calls exactly this update() and discards the id it returns, handing back only the plain index. issue() (credential.ts) goes on using the pre-update statusList.id when creating the credential -- which, by the time the credential is actually created, may already be a deleted row.

Fix

• assignNextIndex() now returns { index, statusListId }, using the id entityService.update() actually produced; issue() uses that for the credential's statusList relation instead of the stale id.
• createStatusListCredential() re-fetches the published copy by documentId, since entityService.create() with publishedAt set can likewise return the draft row's id.
• getOrCreateActiveListForIssuer()'s existence check now filters on status: 'published', so it can never reuse a draft-only id.
• The actual root fix: revocation-list's schema now has draftAndPublish: false. A revocation list is mutable operational state (a counter and a bitstring that change on every issuance and revocation) -- not editorial content someone reviews before publishing. It should never have had Draft & Publish enabled. With it off, update() always mutates the same row, and the id-tracking changes above become defense-in-depth rather than strictly necessary.

Why the existing test suite didn't catch this

revocation-list.test.ts's fake strapi.entityService.update() mutates the existing id in place -- it doesn't match Strapi 5's real behavior for a Draft & Publish content type. I updated the two existing assertions for the new return shape, and added a new test with a mock that faithfully reproduces the real update()-replaces-the-row behavior, asserting assignNextIndex() returns an id that actually still resolves (and that the old one doesn't).

Test plan

• Reproduced the failure against a real Postgres instance via docker-compose up on a clean database (correctly created and published issuer profile + achievement via the admin content-manager API).
• Applied the fix, wiped the database again, and verified end-to-end: issued a synthetic credential (signed, Ed25519Signature2020), verified it (verified: true), revoked it, and verified again (verified: false, not_revoked).
• Updated/added unit tests for assignNextIndex's new return shape and the id-drift scenario specifically.

Scope note: I did not audit whether the same entityService.update()-on-a-published-Draft-&-Publish-entity pattern affects other content types elsewhere in the codebase (several others also have draftAndPublish: true, e.g. credential itself, whose own revoke flow updates the credential row). I scoped this fix to what concretely blocks credential issuance, which is the most severe and immediately reproducible instance of the pattern.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for certo canceled.

Name	Link
🔨 Latest commit	cb6ae34
🔍 Latest deploy log	https://app.netlify.com/projects/certo/deploys/6aa5fff4092f3b00082fe41b

[Readpato]

Please read through this: https://meatproxy.me/

Not taking time to review this, please avoid opening vibe slop PRs.

Closing.