passbolt/passbolt_api · error · ValidationException
The account recovery private key is not valid.
Error message
The account recovery private key is not valid.
What it means
A ValidationException thrown when the account recovery private key entity built in buildAndValidateEntity fails the table's validation rules. The offending entity is attached, exposing field-level errors (e.g. invalid armored key data or missing user_id).
Solutions
- Inspect the entity errors attached to the ValidationException.
- Verify the armored private key is complete and well-formed before submitting.
- Confirm the payload targets the correct user_id.
- Upgrade the client so field names match the server schema.
Example fix
// before
"armored_key": PgpMessage.read(armoredKey).armor // may be undefined on parse failure
// after
if (!armoredKey || !armoredKey.includes('-----END PGP PRIVATE KEY BLOCK-----')) throw new Error('invalid key');
await post('/account-recovery/private-keys', {armored_key: armoredKey}); Defensive patterns
Strategy: validation
Validate before calling
if (!armoredKey?.includes('-----END PGP PRIVATE KEY BLOCK-----')) throw new Error('armored private key incomplete'); Type guard
function isArmoredPrivateKey(v) { return typeof v === 'string' && v.includes('-----BEGIN PGP PRIVATE KEY BLOCK-----') && v.includes('-----END PGP PRIVATE KEY BLOCK-----'); } Try / catch
try { await api.submitRecoveryPrivateKey({armored_key, user_id}); } catch (e) { if (e.body && e.body.account_recovery_private_key) { reportFieldErrors(e.body.account_recovery_private_key); } else { throw e; } } Prevention
- Validate full armor block before submission.
- Verify parseability with your OpenPGP library first.
- Ensure the user_id is a valid UUID of an existing user.
- Sync client field names with the server schema.
When it happens
Trigger: Storing a user's recovery private key with invalid/malformed armored_key data, a missing or invalid user_id, or values violating column constraints.
Common situations: Client uploads a key whose armor is corrupted; wrong user association during response creation; old client producing a field name the current schema doesn't accept.
Understand the failure class
Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.
Related errors
- Could not validate password data.
- Could not validate private key data.
- Could not validate public key data.
- Could not save the account recovery private key.
- Could not save the account recovery setting.
AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17).
Data as JSON: /api/errors/1250b7e0ce2c7c63.
Report an issue: GitHub.
Appendix: source
Thrown at plugins/PassboltEe/AccountRecovery/src/Model/Table/AccountRecoveryPrivateKeysTable.php:186
/** @var \Passbolt\AccountRecovery\Model\Entity\AccountRecoveryPrivateKey $privateKeyEntity */
$privateKeyEntity = $this->newEntity([
'user_id' => $userId,
'data' => $privateKey['data'] ?? [],
'created_by' => $userId,
'modified_by' => $userId,
], [
'accessibleFields' => [
'user_id' => true,
'data' => true,
'account_recovery_private_key_passwords' => true,
'created_by' => true,
'modified_by' => true,
],
]);
if ($privateKeyEntity->hasErrors()) {
$msg = __('The account recovery private key is not valid.');
throw new ValidationException($msg, $privateKeyEntity, $this);
}
return $privateKeyEntity;
}
/**
* Retrieves a list of cleanup methods (first-class callables) implemented by this table.
*
* @return array<int, callable> List of callables
*/
public function getCleanupMethods(): array
{
return [
$this->cleanupHardDeletedUsers(...),
$this->cleanupSoftDeletedUsers(...),
];
}
}View on GitHub (pinned to 31c1bbc10f)