passbolt/passbolt_api · error · ConflictException

The User resource could not be deleted due to validation…

Error message

The User resource could not be deleted due to validation failure

What it means

Generic fallback in UserScimResource::delete(): the soft-delete call returned false or produced entity validation errors that are not the specific 'sole owner of shared content' rule. The SCIM endpoint translates this into an HTTP 409 Conflict. The real cause is only visible in ScimLog (error + stack trace are logged).

Solutions

  1. Inspect ScimLog for 'Unable to delete the user with id `...`' and the logged error/trace to identify the actual validation failure.
  2. Check whether the user was already deleted or is currently marked deleted (GET the user first; treat 404/already-deleted as success for idempotency).
  3. Fix the underlying validation issue (entity state, plugin rule) and retry the DELETE.
  4. Ensure the SCIM client sends deletes only once and handles retries idempotently.

Example fix

// before
curl -X DELETE .../Users/$id  # retries on timeout cause double delete
// after: check current state first
curl .../Users/$id || true
curl -X DELETE .../Users/$id  # only if still active
Defensive patterns

Strategy: try-catch

Validate before calling

$user = $client->get("/scim/v2.0/Users/{$id}");
if ($user->getStatusCode() !== 200) { /* skip: not deletable */ }

Try / catch

try {
    $client->delete("/scim/v2.0/Users/{$id}");
} catch (ClientException $e) {
    if ($e->getResponse()->getStatusCode() === 404) {
        return; // idempotent success: already deleted
    }
    throw $e; // inspect server ScimLog for the real validation error
}

Prevention

When it happens

Trigger: DELETE /scim/v2.0/Users/{id} where Users->softDelete() fails for any validation reason other than sole ownership: e.g. user already deleted, entity in an invalid state, or a table rule blocking deletion.

Common situations: Attempting to delete an already-deleted user through a stale IdP directory; deleting a user blocked by a validation rule added by a plugin; race conditions where two SCIM delete requests arrive concurrently.

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

AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17). Data as JSON: /api/errors/813afd43fa76d4b5. Report an issue: GitHub.

Appendix: source

Thrown at plugins/PassboltEe/Scim/src/Utility/Resource/UserScimResource.php:959

                    'The values of the %s resource has not been set for the `delete` operation',
                    $this->getType()
                )
            );
        }

        $this->assertAdminDeleteAllowed();

        try {
            $result = $this->Users->softDelete($this->userEntity);
            $errors = $this->userEntity->getErrors();
            if (!$result || $errors !== []) {
                if (isset($errors['id']['soleOwnerOfSharedContent'])) {
                    // @todo: send email
                    throw new ConflictException(
                        'The user cannot be deleted because its the sole owner of shared content'
                    );
                }
                throw new ConflictException('The User resource could not be deleted due to validation failure');
            }
        } catch (Exception $e) {
            ScimLog::error(sprintf('Unable to delete the user with id `%s`', $this->userEntity->id));
            ScimLog::error($e->getMessage());
            ScimLog::error($e->getTraceAsString());

            throw new ConflictException('Unexpected error when trying to delete the user.');
        }

        return $this;
    }

    /**
     * @inheritDoc
     */
    public function toSCIM(): array
    {
        if (!$this->id) {

View on GitHub (pinned to 31c1bbc10f)