[FE] Combination of url change and application/octet-stream in response is wrongly calculated as breaking change by system

[Maryna-Ko]

Describe the bug

Precondition: specs with url change in versions and application/octet-stream in response (with no changes)

1856-1.json
1856-2.json

To Reproduce

1. Publish 1856-1, 1865-2 from preconditions as sequence
2. Check API Changes

ER: annotation changes only
AR: breaking change

NOTE: without application/octet-stream in response system calculates changes as annotation

1856-3 without appl octet.json
1856-4 without appl octet.json

Version

APIHUB-25.2.4
Backend v. develop-20250522.053610-2187
Frontend v. 2.12.1-dev.20250521160442

Logs

No response

Additional information

Explanation of Priority: Blocks release window acceptance, which blocks release for almost all products because CLd-Cr can not pass window.

[Maryna-Ko]

Internal issue 1856

[b41ex]

The root cause of the issue is in the contentMediaTypeMappingResolver logic.

• Greedy Matching: findIndex always returns the first match, not the best match
• Wildcard Priority: Wildcards are processed first and "consume" matches that specific types could use better
• No Preference for Exact Matches: The algorithm doesn't prioritize exact matches over wildcard matches

Hence in the case from the issue content media type 'application/octet-stream' is reported as added and removed simultaneously, although the set of media types does not change.

We do not really have a justification (or real-life cases) of complex (wildcard) mapping of content media type between version, so the proposed logic is as follows:

1. Always prefer exact match of media types between version (without regards for wildcards). This rule seems to be a no-brainer.
2. If after exact matches there are exactly one unmapped media type in before/after, and it matches with wildcard- map them (this covers typical cases of changing e.g. application/json to application/* or */* to application/json.
3. For all remaining unmapped media types- report them as added/removed correspondingly. This is a straightforward approach and without justification (real world cases) we decided to keep it simple. This decision could be revised if enough number of real-life scenarios will be collected to justify more complex logic.

[tanabebr]

Hi @b41ex I am fine with proposed logic.
Just to double-check, in this proposed logic considering examples uploaded by Maryna 1856-1.json and 1856-2.json, the code would:

1. Match application/octet-stream from v1 and v2, then realizing that no change was done in this case.
2. Match */* from v1 and v2, then realizing that no change was done in this case.
3. No other unmapped media type is remaining, so logic will end with no change at all.

Is it correct?

[b41ex]

Yes, in the example from the issue we will match */* to */* and application/octet-stream to application/octet-stream and as a result not change to media type will be reported. We are adding this specific unit test as part of the fix for the issue.