HYPERFLEET-1246: Make kind required on ObjectReference, remove ObjectReference2#62
HYPERFLEET-1246: Make kind required on ObjectReference, remove ObjectReference2#62kuudori wants to merge 1 commit into
Conversation
…unused ObjectReference2 The kind field was marked optional in the ObjectReference model but the API validates it as mandatory, causing a mismatch between the spec and runtime behavior. Also removes the unused ObjectReference2<Kind> generic model.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
📝 WalkthroughSummary by CodeRabbitRelease v1.0.23
Walkthrough
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@main.tsp`:
- Line 33: The version string format at line 33 in main.tsp is no longer
compatible with the CI's version extraction logic for the `@info.version` field,
causing the release validation to fail. Either revert the version token back to
the format that the CI parser expects (check previous version formats in git
history), or update the CI version extractor configuration in the same pull
request to handle the new format. Ensure the fix is made in this PR before
merging to unblock the validation job.
In `@package.json`:
- Line 3: The version field in package.json is currently set to a patch version
(1.0.23), but the changes include API schema modifications that make previously
optional request properties required, which constitutes a breaking change to the
public API contract. Update the version to the next breaking-contract version
(typically a minor version bump like 1.1.0 or major version bump like 2.0.0
depending on your versioning strategy) to properly communicate the contract
change to downstream clients and prevent contract drift.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: acfdfd55-ec42-4936-9270-2cd55f794759
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (5)
CHANGELOG.mdmain.tsppackage.jsonschemas/core/openapi.yamlshared/models/common/model.tsp
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
openshift-hyperfleet/architecture(manual)openshift-hyperfleet/hyperfleet-api(manual)openshift-hyperfleet/hyperfleet-sentinel(manual)openshift-hyperfleet/hyperfleet-adapter(manual)openshift-hyperfleet/hyperfleet-broker(manual)
| @service(#{ title: "HyperFleet API" }) | ||
| @info(#{ | ||
| version: "1.0.22", | ||
| version: "1.0.23", |
There was a problem hiding this comment.
Version extraction failure blocks release validation.
CI is failing to parse @info.version from main.tsp after this change, which blocks the validation job. Keep the version: "x.y.z" token parser-compatible at Line [33] or update the CI extractor in the same PR.
As per coding guidelines, "**: Prioritize Critical and Major severity issues."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@main.tsp` at line 33, The version string format at line 33 in main.tsp is no
longer compatible with the CI's version extraction logic for the `@info.version`
field, causing the release validation to fail. Either revert the version token
back to the format that the CI parser expects (check previous version formats in
git history), or update the CI version extractor configuration in the same pull
request to handle the new format. Ensure the fix is made in this PR before
merging to unblock the validation job.
Sources: Coding guidelines, Pipeline failures
| { | ||
| "name": "hyperfleet", | ||
| "version": "1.0.22", | ||
| "version": "1.0.23", |
There was a problem hiding this comment.
Public API contract tightening is shipped as a patch version.
Line [3] sets 1.0.23, while request schemas were tightened (Line [1883], Line [2169], Line [2351] in schemas/core/openapi.yaml, flagged as request-property-became-required). This should be released under the next breaking-contract version to avoid downstream client contract drift.
As per coding guidelines, "**: Prioritize Critical and Major severity issues. ... Validate changes against HyperFleet architecture standards."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@package.json` at line 3, The version field in package.json is currently set
to a patch version (1.0.23), but the changes include API schema modifications
that make previously optional request properties required, which constitutes a
breaking change to the public API contract. Update the version to the next
breaking-contract version (typically a minor version bump like 1.1.0 or major
version bump like 2.0.0 depending on your versioning strategy) to properly
communicate the contract change to downstream clients and prevent contract
drift.
Sources: Coding guidelines, Linters/SAST tools
Summary
kindfield required (was optional) onObjectReferencemodel — aligns spec with API runtime validationObjectReference2<Kind>generic modelContext
Follow-up to #61 which fixed the NodePool example. This addresses the root cause: the model itself declared
kindas optional while the API validates it as mandatory.Test plan
./build-schema.shpassesspectral lintpasses with--fail-severity warnkind— no example changes needed