Conversation
WalkthroughPointer-based optional fields across the OpenAPI schema and generated Go SDK models were converted to nullable wrapper types, enabling explicit three-state semantics (unset, set-to-value, set-to-null) and updating getters, setters, presence checks, and JSON serialization accordingly. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
🔐 TruffleHog Secret Scan✅ No secrets or credentials found! Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉 🕐 Last updated: 2026-04-29 20:17:16 UTC | Commit: 93c3b41 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
sdk/standard/model_expected_power_shelf.go (1)
645-650:⚠️ Potential issue | 🟡 MinorFix
GetLabelsOkdocumentation/behavior mismatch.At Line 645, the comment says explicit nil returns
(nil, true), but the function returns false whenLabelsis nil. This is misleading for SDK consumers.Proposed minimal alignment fix
-// NOTE: If the value is an explicit nil, `nil, true` will be returned +// NOTE: For this map field, nil is treated as not set. func (o *ExpectedPowerShelf) GetLabelsOk() (map[string]string, bool) { if o == nil || IsNil(o.Labels) { - return map[string]string{}, false + return nil, false } return o.Labels, true }As per coding guidelines:
**/*.go: review Go code against clean code and expressiveness.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk/standard/model_expected_power_shelf.go` around lines 645 - 650, The comment for GetLabelsOk is incorrect: it claims an explicit nil returns (nil, true) but the implementation checks o == nil || IsNil(o.Labels) and returns an empty map and false. Update the comment to reflect the actual behavior of GetLabelsOk (i.e., when o is nil or Labels is nil it returns an empty map and false), or alternatively change the function to return (map[string]string(nil), true) when Labels is explicitly nil; adjust either the doc or the IsNil branch in GetLabelsOk accordingly and ensure references to IsNil(o.Labels) and the return values are consistent.sdk/standard/model_expected_switch.go (1)
589-606:⚠️ Potential issue | 🟠 Major
Labelsfield lacks proper nullable support despite misleading documentation.The
GetLabelsOk()method's comment at line 600 incorrectly documents its behavior. It states "If the value is an explicit nil,nil, truewill be returned," but the actual implementation at lines 602–603 returns(map[string]string{}, false)when the field is nil. This violates the stated contract and creates API ambiguity.Additionally,
Labelsis inconsistently modeled compared to other optional fields in the struct. Fields likeRackId,Name, andManufactureruseNullablewrappers (lines 32–48), which properly distinguish between unset and explicitly null values. TheLabelsfield, however, uses a plainmap[string]string(line 50), preventing the distinction. TheToMap()method at lines 735–737 usesif o.Labels != nil, which cannot emit"labels": nullin JSON serialization.Since this is generated code, the root cause lies in the OpenAPI schema or code generator configuration. Ensure the generator produces a
NullableMapwrapper for theLabelsfield to align with the struct's nullable semantics and the documented API contract.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk/standard/model_expected_switch.go` around lines 589 - 606, The Labels field on ExpectedSwitch is not using a nullable wrapper so GetLabelsOk and JSON serialization cannot distinguish unset vs explicit null; update the ExpectedSwitch struct to use the generated nullable map wrapper (e.g., NullableMap[string]string or the project's NullableMapStringString type) for the Labels field, then update GetLabels, GetLabelsOk, Set/Unset helpers and the ToMap() logic to use that nullable wrapper's IsSet/IsNil/Get/Set semantics (adjust references in methods GetLabels, GetLabelsOk, and ToMap) so that GetLabelsOk returns (nil, true) when the wrapper is explicitly null and ToMap emits "labels": null when appropriate.sdk/standard/model_machine.go (1)
701-717:⚠️ Potential issue | 🟠 Major
Labelsfield does not support explicit-null semantics despite the comments promising it.The OpenAPI schema marks
labelsas nullable (oneOfwithtype: 'null', identical tohealthandmetadata), yet the generated Go code does not handle this correctly. The comment at line 712 states "If the value is an explicit nil,nil, truewill be returned," butGetLabelsOk()returnsmap[string]string{}, falseinstead. Additionally,ToMap()omits the field whennilrather than explicitly serializingnull.Since
labelsuses a plainmap[string]string—not a nullable wrapper type likeHealthandMetadata—it cannot distinguish explicit null from unset. Either refactorlabelsto use the same nullable wrapper pattern as the other nullable fields in this PR, or revert the comments to remove the false guarantees of explicit-null handling.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk/standard/model_machine.go` around lines 701 - 717, The comments promise explicit-null semantics for the Labels field but the code uses plain map[string]string so GetLabelsOk, GetLabels and ToMap cannot represent an explicit null; fix by making Labels follow the same nullable-wrapper pattern used for Health and Metadata (e.g., replace the Machine.Labels plain map type with the same Nullable wrapper type used for Health/Metadata, add or reuse a NullableMapStringString type with IsSet()/Get()/Set()/Unset()/IsNil() semantics), then update GetLabels, GetLabelsOk, SetLabels/SetLabelsNil (or equivalent) to use the wrapper and change Machine.ToMap to serialize explicit null when the wrapper is set to nil; alternatively, if you prefer not to support explicit-null, update the comments on GetLabelsOk to remove the claim about explicit-nil handling and ensure ToMap omits the field consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@openapi/spec.yaml`:
- Line 12357: The description string in openapi/spec.yaml contains a double
space ("registration token expires"); update the description value to fix the
spacing and grammar so it reads "Date/time when registration token expires.
Value only exposed to Provider" by removing the extra space between "token" and
"expires" in the description field.
- Around line 17908-17910: The Labels field is declared nullable in the OpenAPI
spec but the SDK uses a plain map[string]string, losing explicit null vs unset
semantics; change the Labels property in affected models (e.g., the model
containing Labels and ExpectedSwitch) to use a NullableLabels wrapper type
(create NullableLabels if missing) and implement the same API pattern used by
other nullable wrappers: methods IsSet(), Get(), Set(map[string]string),
Unset(), plus proper JSON marshal/unmarshal behavior; update all
serialization/deserialization checks (replace direct nil checks like o.Labels !=
nil) to use the NullableLabels.IsSet()/Get() pattern so explicit null, unset,
and set states match the spec.
In `@sdk/standard/model_infrastructure_provider_stats.go`:
- Around line 22-24: The change replaced exported pointer-typed fields on the
InfrastructureProviderStats struct (Machine, IpBlock, TenantAccount) with new
Nullable... wrapper types, which is a breaking API change; restore backward
compatibility by keeping the original exported fields (Machine
*MachineCountByStatus, IpBlock *IpBlockCountByStatus, TenantAccount
*TenantAccountCountByStatus) while introducing the nullable wrappers as either
new fields (e.g., MachineNullable, IpBlockNullable, TenantAccountNullable) or by
adding accessor methods that map between the
NullableMachineCountByStatus/NullableIpBlockCountByStatus/NullableTenantAccountCountByStatus
types and the original pointer types; ensure JSON tags and
marshalling/unmarshalling logic preserve the same serialized shape and
deprecation comments are added to the old fields or accessors to guide future
migration.
---
Outside diff comments:
In `@sdk/standard/model_expected_power_shelf.go`:
- Around line 645-650: The comment for GetLabelsOk is incorrect: it claims an
explicit nil returns (nil, true) but the implementation checks o == nil ||
IsNil(o.Labels) and returns an empty map and false. Update the comment to
reflect the actual behavior of GetLabelsOk (i.e., when o is nil or Labels is nil
it returns an empty map and false), or alternatively change the function to
return (map[string]string(nil), true) when Labels is explicitly nil; adjust
either the doc or the IsNil branch in GetLabelsOk accordingly and ensure
references to IsNil(o.Labels) and the return values are consistent.
In `@sdk/standard/model_expected_switch.go`:
- Around line 589-606: The Labels field on ExpectedSwitch is not using a
nullable wrapper so GetLabelsOk and JSON serialization cannot distinguish unset
vs explicit null; update the ExpectedSwitch struct to use the generated nullable
map wrapper (e.g., NullableMap[string]string or the project's
NullableMapStringString type) for the Labels field, then update GetLabels,
GetLabelsOk, Set/Unset helpers and the ToMap() logic to use that nullable
wrapper's IsSet/IsNil/Get/Set semantics (adjust references in methods GetLabels,
GetLabelsOk, and ToMap) so that GetLabelsOk returns (nil, true) when the wrapper
is explicitly null and ToMap emits "labels": null when appropriate.
In `@sdk/standard/model_machine.go`:
- Around line 701-717: The comments promise explicit-null semantics for the
Labels field but the code uses plain map[string]string so GetLabelsOk, GetLabels
and ToMap cannot represent an explicit null; fix by making Labels follow the
same nullable-wrapper pattern used for Health and Metadata (e.g., replace the
Machine.Labels plain map type with the same Nullable wrapper type used for
Health/Metadata, add or reuse a NullableMapStringString type with
IsSet()/Get()/Set()/Unset()/IsNil() semantics), then update GetLabels,
GetLabelsOk, SetLabels/SetLabelsNil (or equivalent) to use the wrapper and
change Machine.ToMap to serialize explicit null when the wrapper is set to nil;
alternatively, if you prefer not to support explicit-null, update the comments
on GetLabelsOk to remove the claim about explicit-nil handling and ensure ToMap
omits the field consistently.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: bd493ebd-172a-40b1-ba62-66746652c58e
📒 Files selected for processing (32)
docs/index.htmlopenapi/spec.yamlsdk/standard/model_allocation_constraint.gosdk/standard/model_audit_entry.gosdk/standard/model_component_diff.gosdk/standard/model_dpu_extension_service.gosdk/standard/model_dpu_extension_service_deployment.gosdk/standard/model_dpu_extension_service_observability_config.gosdk/standard/model_dpu_extension_service_version_info.gosdk/standard/model_expected_machine.gosdk/standard/model_expected_power_shelf.gosdk/standard/model_expected_switch.gosdk/standard/model_infrastructure_provider_stats.gosdk/standard/model_instance.gosdk/standard/model_instance_type.gosdk/standard/model_instance_type_stats.gosdk/standard/model_ip_block.gosdk/standard/model_machine.gosdk/standard/model_machine_instance_type_stats.gosdk/standard/model_machine_instance_type_summary.gosdk/standard/model_machine_metadata.gosdk/standard/model_rack.gosdk/standard/model_site.gosdk/standard/model_site_machine_stats.gosdk/standard/model_site_machine_stats_by_status_and_health.gosdk/standard/model_site_summary.gosdk/standard/model_sku.gosdk/standard/model_sku_components.gosdk/standard/model_tenant_account.gosdk/standard/model_tenant_stats.gosdk/standard/model_tray.gosdk/standard/model_vpc.go
pbreton
force-pushed
the
fix/some-fields-should-be-nullable-in-openapi-specs
branch
from
93c3b41 to
7ebba12
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
sdk/standard/model_expected_power_shelf.go (1)
634-650:⚠️ Potential issue | 🟠 MajorThe generated
labelsfield cannot preserve the explicit-nullstate declared in the OpenAPI spec.The OpenAPI spec correctly declares
labelsas nullable (oneOf: [#/components/schemas/Labels, null]), but the generated SDK implementsLabelsas a plainmap[string]string, which cannot distinguish between an omitted field and an explicitnullvalue. Consequently:
GetLabelsOk()returns(map[string]string{}, false)whenevero.Labelsis nil, conflating unset and null.ToMap()omits thelabelsproperty entirely wheno.Labels == nil, rather than serializingnull.This discrepancy between spec and SDK is a code generation artifact that should be addressed in the OpenAPI generator configuration (e.g., by using a nullable wrapper type for
labelsinstead of a plain map). The spec itself is correct and should not be modified.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk/standard/model_expected_power_shelf.go` around lines 634 - 650, The Labels field on ExpectedPowerShelf is generated as plain map[string]string so it cannot represent explicit null from the OpenAPI oneOf (Labels|null); update the model to use a nullable wrapper (e.g., a nullable/optional type or *map[string]string with a boolean "isSet" or a generated NullableLabels type) and change the accessor/serializer functions (GetLabels, GetLabelsOk, and ToMap) to use that wrapper: ensure GetLabelsOk returns (nil, true) for explicit null, returns (map, true) for set value, and returns (nil, false) for unset, and ensure ToMap serializes labels as null when the wrapper indicates explicit null and omits the key when unset.sdk/standard/model_expected_switch.go (1)
589-606:⚠️ Potential issue | 🟠 Major
Labelsfield type cannot represent the three-state nullable semantics specified in the OpenAPI schema.Across the SDK, all
Labelsfields are declared as plainmap[string]string, not as a nullable wrapper type. Go's JSON unmarshaling collapses both omitted fields and explicitnulltonil, making it impossible to distinguish them at runtime. TheGetLabelsOk()accessor returnsfalsewhenLabelsisnil, which prevents representing the explicit-null case. Furthermore, the JSON serialization layer cannot emit an explicitnullfor a plain map field.This type mismatch affects all model types with
Labelsfields (ExpectedSwitch, ExpectedPowerShelf, ExpectedMachine, Machine, Instance, InfiniBandPartition, NetworkSecurityGroup, Vpc, and others). The fix requires updating the OpenAPI Generator configuration to emit nullable wrapper types (e.g.,NullableMap[string]string) and corresponding state-management accessors (SetLabelsNil,UnsetLabels), not changes to the OpenAPI specification.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk/standard/model_expected_switch.go` around lines 589 - 606, The Labels fields use plain map[string]string which cannot represent omitted vs explicit-null; update the generated model types (e.g., ExpectedSwitch) so Labels is a nullable wrapper type (e.g., NullableMap[string]string) instead of map[string]string, update accessors like GetLabels, GetLabelsOk and IsNil checks to use the wrapper API (return nil/true for explicit-null via wrapper, and provide Unset/SetNil semantics), and add the state-management methods SetLabelsNil and UnsetLabels (and corresponding changes in ExpectedPowerShelf, ExpectedMachine, Machine, Instance, InfiniBandPartition, NetworkSecurityGroup, Vpc, etc.); implement JSON marshal/unmarshal to emit explicit null when the wrapper is in nil state.
🧹 Nitpick comments (1)
sdk/standard/model_sku.go (1)
195-236: 🏗️ Heavy liftAdd regression coverage for unset vs explicit-null JSON behavior.
This change is part of the new public three-state nullable contract, but the PR only mentions manual testing. A small table-driven SDK test covering unset, explicit
null, and populatedcomponentswould materially reduce the risk of future generator regressions here and in similar models.Also applies to: 324-326
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk/standard/model_sku.go` around lines 195 - 236, Add a table-driven unit test that exercises the three-state nullable behavior for the Components field on Sku: cover (1) unset (field omitted), (2) explicit JSON null, and (3) populated SkuComponents; assert JSON round-trip and behavior of GetComponents, GetComponentsOk, HasComponents, SetComponentsNil, and UnsetComponents to ensure they return/flag nil vs set correctly (e.g., GetComponentsOk returns (nil,true) for explicit null and (nil,false) for unset). Target test helpers around the Sku methods: GetComponents, GetComponentsOk, HasComponents, SetComponentsNil, UnsetComponents and verify marshalling/unmarshalling produces the expected JSON and method results for each case.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@openapi/spec.yaml`:
- Around line 19804-19814: The prometheus and logging branches under the
observability schema are incorrectly marked nullable (they include "type:
'null'"), allowing payloads like { prometheus: null } to satisfy the oneOf;
remove the nullable alternatives from the prometheus and logging branches so the
schema only references the concrete components
(DpuExtensionServiceObservabilityPrometheus and
DpuExtensionServiceObservabilityLogging) and cannot be satisfied by null, and if
nullability is needed for responses make the parent observability field nullable
where referenced or create separate request/response schemas instead of adding
"type: 'null'" to the prometheus/logging branches.
---
Outside diff comments:
In `@sdk/standard/model_expected_power_shelf.go`:
- Around line 634-650: The Labels field on ExpectedPowerShelf is generated as
plain map[string]string so it cannot represent explicit null from the OpenAPI
oneOf (Labels|null); update the model to use a nullable wrapper (e.g., a
nullable/optional type or *map[string]string with a boolean "isSet" or a
generated NullableLabels type) and change the accessor/serializer functions
(GetLabels, GetLabelsOk, and ToMap) to use that wrapper: ensure GetLabelsOk
returns (nil, true) for explicit null, returns (map, true) for set value, and
returns (nil, false) for unset, and ensure ToMap serializes labels as null when
the wrapper indicates explicit null and omits the key when unset.
In `@sdk/standard/model_expected_switch.go`:
- Around line 589-606: The Labels fields use plain map[string]string which
cannot represent omitted vs explicit-null; update the generated model types
(e.g., ExpectedSwitch) so Labels is a nullable wrapper type (e.g.,
NullableMap[string]string) instead of map[string]string, update accessors like
GetLabels, GetLabelsOk and IsNil checks to use the wrapper API (return nil/true
for explicit-null via wrapper, and provide Unset/SetNil semantics), and add the
state-management methods SetLabelsNil and UnsetLabels (and corresponding changes
in ExpectedPowerShelf, ExpectedMachine, Machine, Instance, InfiniBandPartition,
NetworkSecurityGroup, Vpc, etc.); implement JSON marshal/unmarshal to emit
explicit null when the wrapper is in nil state.
---
Nitpick comments:
In `@sdk/standard/model_sku.go`:
- Around line 195-236: Add a table-driven unit test that exercises the
three-state nullable behavior for the Components field on Sku: cover (1) unset
(field omitted), (2) explicit JSON null, and (3) populated SkuComponents; assert
JSON round-trip and behavior of GetComponents, GetComponentsOk, HasComponents,
SetComponentsNil, and UnsetComponents to ensure they return/flag nil vs set
correctly (e.g., GetComponentsOk returns (nil,true) for explicit null and
(nil,false) for unset). Target test helpers around the Sku methods:
GetComponents, GetComponentsOk, HasComponents, SetComponentsNil, UnsetComponents
and verify marshalling/unmarshalling produces the expected JSON and method
results for each case.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: aafe4239-2e66-4c5d-b825-97b3d8706c10
📒 Files selected for processing (32)
docs/index.htmlopenapi/spec.yamlsdk/standard/model_allocation_constraint.gosdk/standard/model_audit_entry.gosdk/standard/model_component_diff.gosdk/standard/model_dpu_extension_service.gosdk/standard/model_dpu_extension_service_deployment.gosdk/standard/model_dpu_extension_service_observability_config.gosdk/standard/model_dpu_extension_service_version_info.gosdk/standard/model_expected_machine.gosdk/standard/model_expected_power_shelf.gosdk/standard/model_expected_switch.gosdk/standard/model_infrastructure_provider_stats.gosdk/standard/model_instance.gosdk/standard/model_instance_type.gosdk/standard/model_instance_type_stats.gosdk/standard/model_ip_block.gosdk/standard/model_machine.gosdk/standard/model_machine_instance_type_stats.gosdk/standard/model_machine_instance_type_summary.gosdk/standard/model_machine_metadata.gosdk/standard/model_rack.gosdk/standard/model_site.gosdk/standard/model_site_machine_stats.gosdk/standard/model_site_machine_stats_by_status_and_health.gosdk/standard/model_site_summary.gosdk/standard/model_sku.gosdk/standard/model_sku_components.gosdk/standard/model_tenant_account.gosdk/standard/model_tenant_stats.gosdk/standard/model_tray.gosdk/standard/model_vpc.go
🚧 Files skipped from review as they are similar to previous changes (6)
- sdk/standard/model_tray.go
- sdk/standard/model_dpu_extension_service_version_info.go
- sdk/standard/model_allocation_constraint.go
- sdk/standard/model_machine.go
- sdk/standard/model_tenant_stats.go
- sdk/standard/model_expected_machine.go
| prometheus: | ||
| $ref: '#/components/schemas/DpuExtensionServiceObservabilityPrometheus' | ||
| oneOf: | ||
| - $ref: '#/components/schemas/DpuExtensionServiceObservabilityPrometheus' | ||
| - type: 'null' | ||
| logging: | ||
| $ref: '#/components/schemas/DpuExtensionServiceObservabilityLogging' | ||
| oneOf: | ||
| - $ref: '#/components/schemas/DpuExtensionServiceObservabilityLogging' | ||
| - type: 'null' | ||
| oneOf: | ||
| - required: | ||
| - prometheus |
There was a problem hiding this comment.
Keep the observability backend branches non-nullable.
This schema already uses a top-level oneOf to require exactly one concrete backend. Making prometheus / logging nullable means payloads like { prometheus: null } now satisfy that contract, so the spec starts accepting an empty observability config.
If only responses need to emit null, keep the parent observability field nullable where it is referenced, or split request/response schemas instead of weakening the branch definitions here.
Suggested schema adjustment
prometheus:
- oneOf:
- - $ref: '#/components/schemas/DpuExtensionServiceObservabilityPrometheus'
- - type: 'null'
+ $ref: '#/components/schemas/DpuExtensionServiceObservabilityPrometheus'
logging:
- oneOf:
- - $ref: '#/components/schemas/DpuExtensionServiceObservabilityLogging'
- - type: 'null'
+ $ref: '#/components/schemas/DpuExtensionServiceObservabilityLogging'As per coding guidelines, openapi/spec.yaml should be reviewed for consistency and correctness.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@openapi/spec.yaml` around lines 19804 - 19814, The prometheus and logging
branches under the observability schema are incorrectly marked nullable (they
include "type: 'null'"), allowing payloads like { prometheus: null } to satisfy
the oneOf; remove the nullable alternatives from the prometheus and logging
branches so the schema only references the concrete components
(DpuExtensionServiceObservabilityPrometheus and
DpuExtensionServiceObservabilityLogging) and cannot be satisfied by null, and if
nullability is needed for responses make the parent observability field nullable
where referenced or create separate request/response schemas instead of adding
"type: 'null'" to the prometheus/logging branches.
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
pbreton
force-pushed
the
fix/some-fields-should-be-nullable-in-openapi-specs
branch
from
7ebba12 to
99b4fe6
Compare
pbreton
force-pushed
the
fix/some-fields-should-be-nullable-in-openapi-specs
branch
from
99b4fe6 to
8477d3c
Compare
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
pbreton
force-pushed
the
fix/some-fields-should-be-nullable-in-openapi-specs
branch
2 times, most recently
from
6848430 to
56b4e64
Compare
Signed-off-by: Patrice Breton <pbreton@nvidia.com>
pbreton
force-pushed
the
fix/some-fields-should-be-nullable-in-openapi-specs
branch
from
56b4e64 to
da03ff2
Compare
thossain-nv
left a comment
thossain-nv
left a comment
There was a problem hiding this comment.
Looks good, thank you for this @pbreton
2 participants
Description
Some fields in OpenAPI specs are not listed as nullable but can in fact be returned 'null' by the server: this PR fixes it.
Note: the only changes are in openapi/spec.yaml. Everything else is generated or induced (sdk/simple).
Type of Change
Services Affected
None
Breaking Changes
In the generated Go SDK some fields previously pointers are now Nullable objects.
Testing