[BUG] Askar → Askar-AnonCreds Wallet Upgrade: Data Loss (Credentials, Schemas, Cred Defs Disappear)

[nb-vivek-bodar]

Environment

Component	Version / Value
ACA-Py version	1.6.0
Original wallet type	askar
Target wallet type (issuer)	askar-anoncreds
Target wallet type (holder 1)	askar-anoncreds
Target wallet type (holder 2)	kanon-anoncreds
Agents involved	1 Issuer, 2 Holders

Summary

After successfully triggering the /anoncreds/wallet/upgrade endpoint and restarting each agent with the wallet type updated in its config (askar → askar-anoncreds / kanon-anoncreds), all previously created records become inaccessible:

• The issuer can no longer see its previously created schemas and credential definitions via the new /anoncreds/* endpoints.
• Both holders can no longer see their previously issued credentials via /credentials.

The upgrade endpoint reports "success": true in all cases, but the post-upgrade state is effectively empty, as if the upgrade did not migrate the records into the new wallet backend.

Steps to Reproduce

Flow 1 — Holder 1

1. Confirm pre-upgrade state (wallet type askar):

   GET /credentials?count=10&start=0
   

   Response:

   {
     "results": [
       {
         "referent": "39f2e951-4c51-491d-b533-4d1e60d64f77",
         "schema_id": "E5agQdZ6NHuqn9NExsaYUd:2:Driving_License:1.0",
         "cred_def_id": "E5agQdZ6NHuqn9NExsaYUd:3:CL:3220251:Driving_License",
         "rev_reg_id": null,
         "cred_rev_id": null,
         "attrs": {
           "first_name": "John",
           "dob_dateint": "19900101",
           "last_name": "Doe"
         }
       }
     ]
   }

2. Trigger the wallet upgrade:

   POST /anoncreds/wallet/upgrade?wallet_name=test-lob-holder_wallet
   

   Response:

   {
     "success": true,
     "message": "Upgrade to anoncreds has been triggered for wallet test-lob-holder_wallet"
   }

3. Agent process stops on its own after the upgrade is triggered.

4. Manually edit the agent's config file, changing wallet-type from askar to askar-anoncreds, then restart the agent.

5. Re-check credentials:

   GET /credentials?count=10&start=0
   

   Response:

   {
     "results": []
   }

Expected: The previously issued credential (referent 39f2e951-...) should still be present after the upgrade.
Actual: results is empty — the credential appears lost.

Flow 2 — Holder 2 (target: kanon-anoncreds)

Same steps as Flow 1, but the wallet type set post-upgrade was kanon-anoncreds instead of askar-anoncreds.

1. Pre-upgrade GET /credentials?count=10&start=0 returns one credential (referent 5b537958-48cd-4c3d-a8fb-b16b2c2ca120, same schema/cred def as Holder 1).
2. POST /anoncreds/wallet/upgrade?wallet_name=test-lob-holder1_wallet → {"success": true, ...}.
3. Agent stops; config manually updated wallet-type: askar → wallet-type: kanon-anoncreds; agent restarted.
4. Post-upgrade GET /credentials?count=10&start=0 → {"results": []}.

Same data-loss symptom as Flow 1, independent of whether the target wallet type is askar-anoncreds or kanon-anoncreds.

Flow 3 — Issuer

1. Pre-upgrade, confirm existing schema and cred def (wallet type askar):

   GET /credential-definitions/created
   

   { "credential_definition_ids": ["E5agQdZ6NHuqn9NExsaYUd:3:CL:3220251:Driving_License"] }

   GET /schemas/created
   

   { "schema_ids": ["E5agQdZ6NHuqn9NExsaYUd:2:Driving_License:1.0"] }

2. Trigger the wallet upgrade:

   POST /anoncreds/wallet/upgrade?wallet_name=test-lob-issuer_wallet
   

   { "success": true, "message": "Upgrade to anoncreds has been triggered for wallet test-lob-issuer_wallet" }

3. Agent stops; config manually updated wallet-type: askar → wallet-type: askar-anoncreds; agent restarted.

4. Re-check via the new AnonCreds endpoints:

   GET /anoncreds/schemas
   

   { "schema_ids": [] }

   GET /anoncreds/credential-definitions
   

   { "credential_definition_ids": [] }

Expected: Schema E5agQdZ6NHuqn9NExsaYUd:2:Driving_License:1.0 and cred def E5agQdZ6NHuqn9NExsaYUd:3:CL:3220251:Driving_License should be visible under /anoncreds/schemas and /anoncreds/credential-definitions after the upgrade.
Actual: Both lists are empty.

Observations / Possible Root Cause

• All three flows show the same pattern: POST /anoncreds/wallet/upgrade returns success: true, but the agent process then stops on its own rather than completing the upgrade in-place and staying up.
• The requirement to manually edit wallet-type in the config file and restart suggests the upgrade endpoint does not itself flip the wallet mode — it may only be migrating storage while the caller is still expected to do a manual cutover, and something in that manual step (or in the migration itself) is not carrying the records over.
• This reproduces consistently across 3 independent agents/wallets (1 issuer, 2 holders) and 2 different target wallet types (askar-anoncreds, kanon-anoncreds), suggesting this is not an isolated/config-specific issue.

Impact

Any production issuer/holder wallet on askar that goes through the documented anoncreds upgrade path per the ACA-Py 1.6.0 docs would lose all existing credentials, schemas, and credential definitions, with no apparent recovery path short of re-issuance from scratch. This makes the upgrade path unsafe to use as documented.

Questions for the ACA-Py Team

1. Is a full agent restart with a manual wallet-type config change actually the intended flow after calling /anoncreds/wallet/upgrade, or should the upgrade be handled entirely by the endpoint without a config edit + restart?
2. Is there a required delay / progress-polling step between triggering the upgrade and restarting the agent that we're missing (i.e., are we restarting before the async migration job finishes)?
3. Is kanon-anoncreds a supported/expected wallet-type value for this upgrade path in 1.6.0, or should it always target askar-anoncreds regardless of the original custom wallet type name?
4. Is there a known issue/limitation where post-upgrade AnonCreds objects (schemas, cred defs, stored credentials) are not migrated into the new wallet format and require manual migration tooling?

[jamshale]

I don't understand what is happening with this reported issue. We have substantial tests covering this feature that are run for every PR and daily.

https://github.com/openwallet-foundation/acapy/blob/main/scenarios/examples/anoncreds_issuance_and_revocation/example.py
https://github.com/openwallet-foundation/acapy/blob/main/scenarios/examples/restart_anoncreds_upgrade/example.py

[jamshale]

The response payload is different for the anoncreds endpoints. Any chance that is what is appearing as a problem?