bug: infrahubctl schema check exits 0 when the schema is invalid

[BeArchiTek]

Component

infrahubctl

Infrahub SDK version

1.23.1

---

Current Behavior

infrahubctl schema check prints the validation errors and then exits 0. The
process reports success while telling the reader the schema is invalid.

In infrahub_sdk/ctl/schema.py, check():

success, response = await client.schema.check(schemas=..., branch=branch)

if not success or not response:
    display_schema_load_errors(response=response or {}, schemas_data=schemas_data)
    return          # <-- plain return: no raise, no non-zero exit

The failure path returns rather than raising, so Typer exits with status 0.

The sibling command in the same file does it correctly. load() raises on its
failure path; check() does not. That inconsistency is what makes this look like an
oversight rather than a deliberate "check never fails the build" choice.

Expected Behavior

schema check should exit non-zero when the schema does not validate, so it can be used
as a gate. The one-line change would be to replace the return with:

raise typer.Exit(code=1)

which matches how load() already behaves.

Steps to Reproduce

1. Point infrahubctl at a running Infrahub instance that already holds data for a kind.
2. Make a change the server rejects against existing data — for example remove a generic
   from a node's inherit_from, which is refused once nodes of that kind exist.
3. Run:

infrahubctl schema check schemas/ --branch <branch>
echo "exit=$?"

4. Observe the command prints Unable to load the schema with one constraint violation
   per affected kind and per existing node — and then prints exit=0.

Additional Information

Why the impact is larger than the fix. The natural use of schema check is as a
pre-merge or pre-deploy gate, and a gate that always returns 0 does not gate. Any CI step
of the form infrahubctl schema check schemas/ passes unconditionally, including on
exactly the schema changes the server will later refuse. The failure then surfaces at
schema load time, after the pipeline has already reported green.

We hit this while validating schema changes against a branch holding existing data: the
command printed the violations clearly, and the surrounding automation treated the run as
a success because it was checking the exit status rather than parsing stdout.

Workaround, for anyone who finds this before it is fixed: do not trust the status —
capture stdout and grep it, e.g. fail the step if the output contains Unable to load the schema. That is brittle but it is what the current behaviour forces.

Environment: macOS arm64, Python 3.13.