Skip to content

Some schemas erroneously pass strict validation checks #5991

Open

Description

@Vessel9817

Area with issue?

Build server

✔️ Expected Behavior

If a schema isn't included in ajvNotStrictMode, it should be subject to strict validation in its entirety. That means that the use of type unions in schemas should result in strict validation failing with the following error message:

Error: strict mode: use allowUnionTypes to allow union type keyword at "..." (strictTypes)

❌ Actual Behavior

Strict validation passes in exceptional circumstances.

JSON, YAML, or TOML file that does not work.

The current revision of host-meta.json, whose issues have since been fixed in #5990. Other such cases exist.

IDE or code editor.

None

Are you making a PR for this?

No, someone else must create the PR.

Activity

  1. added theissue type on Jul 15, 2026
  2. Vessel9817 commented on Aug 31, 2026

    @Vessel9817
    ContributorAuthor

    I haven't seen this issue arise in quite some time, so I'm wondering if this issue is specific to schemas using draft-04, or otherwise prior to draft-07.

  3. Vessel9817 commented on Sep 6, 2026

    @Vessel9817
    ContributorAuthor

    As demonstrated by 2633e7a (draft-07), this is an incorrect assumption.

  4. hyperupcall commented on Sep 15, 2026

    @hyperupcall
    Member

    In the build system, I believe we don't enable all strict validation checks, but a large subset. Maybe this is what is being encountered? In the past, we also have excluded some large files from certain checks (separate from ajvNotStrictMode). But I'm not sure if host-meta.json is one of them.

  5. Vessel9817 commented on Sep 15, 2026

    @Vessel9817
    ContributorAuthor

    That's the thing. In migration, I've frequently encountered this error, which is why "type": [ is one of the first things I check for. If there's a separate exclusion from ajvNotStrictMode, for some reason, it's highly likely to be the cause. Although, I searched the entire repository for the text host-meta, and it only appeared in schemas and their corresponding catalog entry, so I'm not sure where this extraneous exclusion would be located, assuming it's based on file names, rather than size.

  6. added a commit that references this issue on Sep 16, 2026
    bc061a2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions