Fix several issues with oneof responses

[ezilber-akamai]

📝 Description

Fixed oneOf response properties being overwritten during schema aggregation. When a oneOf defines the same property across multiple branches, keep the most complete definition instead of letting a later, emptier branch overwrite it. This fixes fields like public.ipv6.ranges being dropped from output.

Also fixed an issue with oneOf schemas in _parse_response_model that was causing nested response data to be displayed incorrectly.

✔️ How to Test

make test-unit
make test-int TEST_CASE=test_interface_update (was previously failing)
make test-int TEST_SUITE=firewalls (was previously failing)

[mawilk90]

The tests passed locally. Thanks for addressing it!

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

🟡 Changes recommended

Richness ties remain order-dependent, and scalar oneOf arrays can disappear from generated output.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

🟡 Changes recommended

Unresolved moderate schema-aggregation issues and missing coverage block approval.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (3)

linodecli/baked/util.py:121

• The <= comparison also discards equal-richness definitions. Two branches can define the same object property with disjoint nested fields but the same score, and allOf branches are conjunctive, so keeping only the first loses fields that must be exposed. Use a composition-aware merge for ties/allOf rather than a winner-takes-all selection.

            if key in properties and _schema_richness(
                value
            ) <= _schema_richness(properties[key]):
                continue

            properties[key] = value

linodecli/baked/util.py:52

• Each duplicate-property comparison recursively walks properties, compositions, and items. The depth cap prevents unbounded recursion but not exponential work for a cyclic schema with multiple recursive children; a branching cycle can expand to roughly 2^32 visits during one comparison and make baking unresponsive. Memoize scores by schema identity or track active nodes in addition to the depth limit.

    properties = get(schema, "properties")
    if properties:
        for _, prop in properties.items():
            score += 1 + _schema_richness(prop, _depth + 1)

linodecli/baked/util.py:58

• _schema_richness adds 1 for every composition branch even when that branch contributes no object properties. A property defined as oneOf: [{type: string}, {type: integer}] therefore scores 2 and can beat a competing object definition with one nested field (score 1); the aggregator keeps the scalar oneOf schema, and _parse_response_model then emits only the parent value instead of the nested field. Score renderable structure rather than counting scalar alternatives, or merge the alternatives before choosing a definition.

    # Account for composite (oneOf/allOf/anyOf) definitions by summing the
    # richness of each branch.
    for composition_field in ("oneOf", "allOf", "anyOf"):
        for branch in get(schema, composition_field) or []:
            score += 1 + _schema_richness(branch, _depth + 1)

• Files reviewed: 5/5 changed files
• Comments generated: 3
• Review effort level: Lite

[yec-akamai]

I think we can apply this comment for the edge case

[yec-akamai]

Tests passed locally!