forms: DynamicForm mistypes every array-valued schema key when 'schema' is assigned as a QVariant instead of bound

[Yaraslaut]

DynamicForm.qml types every field from p.type, and reaches the array form
({"type":["integer","null"]}, which is what schemaJson emits for a rule-3
strong id under $defs) through Array.isArray:

const types = Array.isArray(p.type) ? p.type : (p.type === undefined ? [] : [p.type])
...
isInteger: types.indexOf("integer") !== -1,
jsonType: types.length > 0 ? types[0] : ""

Array.isArray is false for a QVariantList. So when schema reaches the form
as a QVariant rather than as a JS object — an initial property, a
setProperty from C++, createTemporaryObject(..., {schema: ...}) — every
array-valued type is wrapped instead of unpacked, isInteger comes out false,
and the field falls through to the plain-text encoding: the id is submitted as a
quoted JSON string, which the server rejects with parse_number_failure.
That is the same symptom morph#189 fixed for the anyOf shape, reappearing
through a different door.

Verification status: reproduced, and not a shipped-app defect

Measured at 1f7a4619, Qt 6.11.2, QT_QPA_PLATFORM=offscreen, via a scratch
tst_*.qml through morph_forms_qml_tests -input <dir>, using
schemaJson<kanban::AddComment>() verbatim.

Declarative binding — the shape every shipped app uses
(schema: page.schemas["AddComment"] || ({}), and schema: JSON.parse(...)):

BOUND:  resolved.type=["integer","null"]  Array.isArray(resolved.type)=true
BOUND FIELD taskId  jsonType="integer"  isInteger=true
BOUND ready=true  previewLine={"taskId":7,"body":"hello"}      <- number. correct.

INLINE: resolved.type=["integer","null"]  Array.isArray(resolved.type)=true
INLINE FIELD taskId  jsonType="integer"  isInteger=true
INLINE ready=true  previewLine={"taskId":7,"body":"hello"}     <- number. correct.

Same schema, assigned as an initial property
(createTemporaryObject(formComponent, this, { schema: ... })):

AddComment FIELD taskId  jsonType=["integer","null"]  isInteger=false
AddComment ready: true
AddComment previewLine: {"taskId":"7","body":"hello"}          <- quoted. wrong.

Note jsonType in the broken case: it is the whole ["integer","null"] array,
which is types[0] when types == [["integer","null"]] — i.e. the
Array.isArray branch was not taken.

So no shipped rung is currently affected, and I am filing this as a
robustness gap rather than a live bug: every app binds schema declaratively.
What is affected is anything that hands the form a schema imperatively, which
is the natural thing for a C++-driven test to do and the thing I did first when
writing one (examples/kanban/tests/test_gui_forms_render.cpp reached the
correct result only because the schema goes through QML bindings there).

Not verified: whether x-rules, x-layout or any other array-valued schema
key degrades the same way under the same conversion. Very likely — the same
Array.isArray idiom appears at :186 (anyOf/oneOf branches), :249-252
(required), :411-431 (x-layout groups) — but I only measured type.

Why it is worth fixing rather than documenting

The failure is silent and type-shaped: no warning, no error, a ready form, and
a body the server refuses. A one-line helper (function asArray(v) { return Array.isArray(v) ? v : (v && typeof v.length === 'number' && typeof v !== 'string' ? Array.prototype.slice.call(v) : ...) }) or an explicit
JSON.parse(JSON.stringify(schema)) normalisation at the schema property
would remove a whole class of "works in the app, mistyped in the harness"
confusion.

What would change the verdict

Close when a DynamicForm given the same schema as a QVariantMap and as a JS
object produces identical fields and identical previewLine, asserted by a
test in src/qt/forms/tests/. Re-open if a later refactor reintroduces a bare
Array.isArray on schema data.

[Yaraslaut]

Triage: rescope — real and reproduced, but the scope claim in the title is wrong in both directions

Premise: confirmed, independently. Reproduced the mechanism with no morph code at all — one 40-line QML file through a bare QQmlEngine (Qt 6.11.2, QT_QPA_PLATFORM=offscreen), one schema, assigned both ways:

BOUND    type: isArray = true  | length = 2 | t[0] = "integer" | wrapped[0] = "integer"
INITPROP type: isArray = false | length = 2 | t[0] = "integer" | wrapped[0] = ["integer","null"]

createObject(parent, {schema: ...}) round-trips the value through QVariant, Array.isArray is false for the resulting QVariantList, and types[0] is the whole array — exactly the reported jsonType=["integer","null"].

The other array-valued keys do not degrade

The issue calls it "very likely" that required, x-layout and x-rules degrade the same way. Measured on the same object, they do not:

INITPROP required:        isArray = false | length = 2 | has indexOf = true | indexOf('body') = 1
INITPROP x-layout.groups: isArray = false | length = 1 | has map = true     | groups[0].title = G
INITPROP x-rules:         isArray = false | length = 1 | has length prop = true

A QVariantList still carries .length, .indexOf, .map and element access. required (:250, :326 — required.indexOf(name)), x-layout (:410-411 — groups.length / groups.map) and x-rules (:72) never call Array.isArray, so they come out correct. optionRows (:1074/:1077) is unaffected for a different reason: its input is JsonExact.parse(payload) output — a genuine JS array — not schema data.

The affected set is exactly the two Array.isArray calls on schema data: :256 (p.type) and :186 (p.anyOf/p.oneOf). Not "every array-valued schema key".

And :186 is a second failure the issue does not name

Replicating resolveProp (:175-203) verbatim over the morph#189 shape ({"anyOf":[{"$ref":"#/$defs/int64_t"},{"type":"null"}]}):

BOUND    isArray(anyOf) = true  | resolved type = "integer" | isInteger = true  -> numeric encoding
INITPROP isArray(anyOf) = false | resolved type = undefined | isInteger = false -> PLAIN-TEXT (morph#189 symptom)

So this is not "the same symptom as morph#189 reappearing through a different door" — it is morph#189's own fix going inert on this path. A nullable $ref member regresses to the pre-#189 behaviour independently of type, and the comment at :180-185 explaining why that branch exists is the thing being skipped.

What to rewrite before anyone builds it

• Title and body: the scope is the two Array.isArray call sites on schema data, one of which is DynamicForm serialises boolean fields, and anyOf integer fields, as JSON strings — the server rejects both #189's fix — not "every array-valued schema key".
• Both proposed fixes are confirmed workable. The asArray helper is needed at exactly two sites. JSON.parse(JSON.stringify(schema)) also works — JSON.stringify on the wrapper produced ["integer","null"] correctly in the probe — and has the advantage of immunising any future site, which matters given the :186 finding.
• The close condition is good as written; extend it to cover an anyOf-over-$ref member, since that is the second site and the one that silently un-fixes DynamicForm serialises boolean fields, and anyOf integer fields, as JSON strings — the server rejects both #189.

Dropping bug: the issue's own verification establishes that no shipped rung is affected (every app binds schema declaratively), so this is a robustness gap, not a defect in shipped behaviour.

What would change this verdict: a measurement showing required, x-layout or x-rules mis-parsed under the QVariant path — i.e. a QVariantList on which .indexOf/.map/.length do not work. The probe above says they do.