Identity creation returns internal Drive error for duplicate unique public key

[thephez]

Expected Behavior

Creating an identity with an already-registered unique public key should fail validation with DuplicatedIdentityPublicKeyIdStateError.

The request should not reach Drive’s storage safety guard or return an internal error.

Current Behavior

Repeating address-funded identity creation with the same unique master authentication key returns:

Failed to create identity from addresses: Drive internal error: oWdtZXNzYWdleMRzdG9yYWdlOiBpZGVudGl0eTogYSB1bmlxdWUga2V5IHdpdGggdGhhdCBoYXNoIGFscmVhZHkgZXhpc3RzOiB0aGUga2V5IGFscmVhZHkgZXhpc3RzIGluIHRoZSB1bmlxdWUgc2V0IFszLCA5NywgMjU0LCA4NCwgMjA5LCAxNDIsIDE3OSwgMTQ1LCAzNSwgMTcsIDQyLCAxNDEsIDE3MywgMTE5LCAxMzYsIDI0MSwgMjM5LCAxMzEsIDE5MywgNDRd

The encoded payload contains:

storage: identity: a unique key with that hash already exists:
the key already exists in the unique set [3, 97, 254, 84, 209, 142, 179, 145, 35, 17, 42, 141, 173, 119, 136, 241, 239, 131, 193, 44]

The duplicate is detected only by Drive during insertion rather than by consensus state validation. The SDK also exposes the encoded Drive error payload instead of its decoded message.

Possible Solution

IdentityCreateFromAddressesTransition calls validate_unique_identity_public_key_hashes_not_in_state, which queries the unique-key index before producing the identity-create action.

Drive performs a second check when inserting the unique-key reference. That guard finds the existing hash and returns IdentityError::UniqueKeyAlreadyExists.

The internal error therefore occurs because the state validator does not observe the existing key, but the later Drive insertion guard does:

1. State validation queries the unique-key index and treats the transition as valid.
2. Identity execution begins.
3. Drive checks the same uniqueness invariant during insertion.
4. Drive finds the existing hash and raises an internal storage error.

A committed-state regression test for duplicate unique keys currently passes, suggesting the failing case may involve state visibility or validation timing—for example, a repeated request validated against a state snapshot that does not yet include the earlier identity, while insertion executes against a transaction where the key is present.

The validation and insertion paths should use a consistent view of the unique-key index so the collision is returned as DuplicatedIdentityPublicKeyIdStateError before Drive operations are generated or applied.

The SDK should also decode the Drive error metadata rather than exposing its Base64/CBOR representation.

Steps to Reproduce (for bugs)

1. Create a new identity with a random identity ID.
2. Use TEST_PLATFORM_ADDRESS_KEY_B as its unique master authentication key.
3. Call sdk.addresses.createIdentity(...), funding it from Platform Address A.
4. Repeat identity creation with another random identity ID and the same master key.

Context

Reusing a unique identity key is expected to fail. The issue is the error classification: Platform returns an internal storage error instead of the intended duplicate-public-key consensus error.

Your Environment

• Network: testnet
• SDK version: evo-sdk 4.0.0
• Operating System and version: Ubuntu