bitwarden/server · error · BadRequestException

conditions.Error!

Error message

conditions.Error!

What it means

Thrown as a BadRequestException (HTTP 400) by AccessRuleWriteValidator.ValidateAsync when the IAccessRuleValidator.Validate call on rule.Conditions returns an invalid result. The exception message is dynamic — it is conditions.Error!, so the specific text depends on what condition rule failed validation (e.g., invalid time window, unsupported operator, malformed expression).

Source

Thrown at bitwarden_license/src/Services/Pam/Services/AccessRuleWriteValidator.cs:45

    }

    public async Task<List<Guid>> ValidateAsync(Guid organizationId, AccessRule rule,
        IEnumerable<Guid> collectionIds, Guid? existingRuleId = null)
    {
        if (string.IsNullOrWhiteSpace(rule.Name))
        {
            throw new BadRequestException("Name is required.");
        }

        if (rule.AllowsExtensions && rule.MaxExtensionDurationSeconds is not > 0)
        {
            throw new BadRequestException("A maximum extension length is required when extensions are allowed.");
        }

        var conditions = _conditionsValidator.Validate(rule.Conditions);
        if (!conditions.IsValid)
        {
            throw new BadRequestException(conditions.Error!);
        }

        await ValidateNameIsUniqueAsync(organizationId, rule.Name, existingRuleId);

        return await ValidateCollectionsAsync(organizationId, collectionIds, existingRuleId);
    }

    private async Task ValidateNameIsUniqueAsync(Guid organizationId, string name, Guid? existingRuleId)
    {
        var siblings = await _repository.GetManyByOrganizationIdAsync(organizationId);
        if (siblings.Any(r => r.Id != existingRuleId && string.Equals(r.Name, name, StringComparison.OrdinalIgnoreCase)))
        {
            throw new BadRequestException("A rule with that name already exists.");
        }
    }

    private async Task<List<Guid>> ValidateCollectionsAsync(Guid organizationId, IEnumerable<Guid> collectionIds,
        Guid? existingRuleId)

View on GitHub (pinned to e93b962371)

Solutions

1. Read the dynamic message in the 400 response — it identifies which condition rule failed.
2. Validate the conditions payload against the current AccessRule conditions schema before submitting.
3. Check for deprecated condition operators or fields after a server upgrade.
4. Simplify conditions to isolate which field triggers the error, then re-add complexity.

try { await pamClient.CreateAccessRuleAsync(orgId, rule); }
catch (HttpRequestException ex) when (ex.Message.Contains("conditions") || /* 400 on conditions */)
{ // read ex.Message for the specific condition-validation failure
  logger.Error("Conditions invalid: {Reason}", ex.Message);
  // fix the conditions payload per the error text, then retry }

When it happens

Trigger: Creating or updating a PAM AccessRule where the 'conditions' object fails the conditions validator — e.g., an invalid schedule, an unsupported condition operator, a malformed time range, or a missing required condition field. The exact failure is described in the dynamic error message.

Common situations: Conditions JSON has an invalid time-window format. An unsupported or deprecated condition operator is used. A required sub-field of conditions (e.g., IP range, schedule) is missing or malformed. Version mismatch where the client sends a newer condition schema the server rejects.

Related errors

• Name is required.
• A maximum extension length is required when extensions are a
• result.AsError.Message
• ExternalId cannot exceed 300 characters.
• ExternalId cannot exceed 300 characters.

AI-assisted analysis of bitwarden/server@e93b962371 (2026-08-13). Data as JSON: /api/errors/fdab516d5ed2a16b. Report an issue: GitHub.