test: added EIA integration tests#56
Merged
Merged
Conversation
tutkat
changed the title
…ch EIA routing protocol Gson conflict Setting the flag to true made all generated models strict, rejecting real API fields (e.g. Port.cvpId) and breaking deserialization broadly. Revert to false (tolerant additionalProperties) and instead fix the EIA routing protocol Gson 'multiple JSON fields additionalProperties' collision via patch 002 (applied in patch-post after regeneration). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…mplate
With disallowAdditionalPropertiesIfNotPresent=false every model gets an
additionalProperties holder. For allOf-inheritance models this produced
the field in BOTH parent and child, causing Gson to fail at runtime:
'declares multiple JSON fields named additionalProperties'.
Vendor pojo.mustache + additional_properties.mustache and wrap the
additionalProperties field/accessors/equals/hashCode/toString in
{{^parent}} so only root classes declare it; children inherit it.
Fixes the collision for all ~126 inheritance models at once, so the
per-class patch 002 is no longer needed and is removed.
Validated by regenerating the full SDK with this template: it compiles,
Port stays tolerant (accepts unknown fields like cvpId), and the
InternetAccess routing protocol children no longer duplicate the field.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…espace churn
The {{^parent}} guard was placed on the same line as
{{#isAdditionalPropertiesTrue}}, so jmustache no longer treated those
lines as standalone and emitted their trailing newlines, adding blank
lines to every generated model (huge no-op diff after sync).
Put each section tag on its own line so they are stripped as standalone.
Verified: root models (e.g. Port) regenerate byte-identical to stock,
children only lose the duplicated additionalProperties, full SDK compiles.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The API omits 'order' in InternetAccessService responses (e.g. while PROVISIONING), but the spec marks it required, so the generated validateJsonElement threw 'The required field order is not found'. Drop 'order' from the schema's required list. Apply it both to the committed oas3.patched (consumed by codegen) and as a spec patch so a full spec re-sync re-applies it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
displague
reviewed
Jun 26, 2026
| - completed | ||
| workflow_dispatch: | ||
| pull_request: | ||
| types: [labeled] |
Member
There was a problem hiding this comment.
depends on a 'run-fabric-tests' label to be created. ok. conditional looks ok to me to run when we want it and not otherwise.
displague
approved these changes
Jun 26, 2026
shahbhoomi
approved these changes
Jun 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.