DEFAULT_MAX_CHILDREN

Default ceiling on children visited per container.

Sixty-five thousand five hundred and thirty-six, raised from 4096, and the number outlived the argument for it. It was raised because this bound did not behave like the others: every budget in the engine either reports having fired or is declined symmetrically by the reader — maxPaths overflow is counted in InferredSchema.truncatedPathEstimate, IndexOptions.maxTermsPerSegment drops the index for the segment so it reads as not covered and is scanned, maxTermBytes is applied to the same bytes by the planner, a truncated bound widens — and this one did none of that. A container wider than it was walked to it and nothing said so. Raising the number was named at the time as a mitigation rather than a fix, with the fix identified as a coverage signal, which would let the bound come back down.

Both halves now report, and they report differently because they are different failures. An index build that hits this bound leaves its segment not covered, so the question is answered by a scan and the walk that scans carries no bound at all — an answer no longer depends on this number. A sketch that hits it has no such escape and needs none: an under-counted path is a recommendation that ranks low, not a document that goes missing. So the catalog reports instead, as TruncatedWalkException in SchemaCatalog.problems, naming the container and what it skipped.

The number itself still stands where truncating is genuinely the better answer rather than merely the cheaper one: past 65 536 children a container is generated data, and below it a walk is O(65 536) against the segment write it rides on. What changed is the cost of being wrong about it. A corpus with containers wider than this — the measured protobuf-JSON dump holds 12 040 elements under one path — now pays in coverage and in an understated model, both of which are visible, rather than in answers that are quietly short.