Skip to content

oneOf subtypes not linked correctly to parent type #233

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 tasks done
sdufel opened this issue Sep 17, 2024 · 3 comments · Fixed by #234
Closed
2 tasks done

oneOf subtypes not linked correctly to parent type #233

sdufel opened this issue Sep 17, 2024 · 3 comments · Fixed by #234
Labels

Comments

@sdufel
Copy link
Contributor

sdufel commented Sep 17, 2024

Preliminary checks

  • I am using the latest version, or the latest version that corresponds to my Oxide installation.
  • There is no open issue that reports the same problem.

What was the expected behaviour

For API types specified to return oneOf a number of types, the SDK parses responses to the correct type.

What is the current behaviour and what actions did you take to get there

Specifically for the Datum type, it appears that all type options are being generated - however the generic type is being created as the first variant, rather than a generic type / interface.

Generated code example:

// Datum is a `Datum` is a single sampled data point from a metric.
type Datum struct {
	// Datum is the type definition for a Datum.
	Datum *bool `json:"datum,omitempty" yaml:"datum,omitempty"` // <- this is only one of the possible type for a Datum
	// Type is the type definition for a Type.
	Type DatumType `json:"type,omitempty" yaml:"type,omitempty"`
}

In this case, DatumBool, DatumI32, etc are all created, but they are not available as fields of the Datum struct.

When invoking the disk_metrics_list endpoint, this manifests as the following error:

error decoding response body: json: cannot unmarshal object into Go struct field Datum.items.datum.datum of type bool

Go SDK version

v0.1.0-beta7

Operating system

macOS 14.6.1

Anything else you would like to add?

No response

@sdufel sdufel added the bug label Sep 17, 2024
@wfchandler
Copy link
Contributor

Thanks for the detailed report @sdufel. We've start working on a fix for this.

In the longer term, we are planning on migrating these metrics into the /v1/timeseries/query endpoint, but we don't have a firm date on when that will happen. This will require some changes to how we handle authorization internally, see oxidecomputer/omicron#6155 and oxidecomputer/omicron#5298 (comment) for more details.

Let us know if you have any questions or concerns.

@karencfv
Copy link
Collaborator

Thanks for taking the time to let us know about this bug @sdufel! I've merged a commit that fixes this issue. I hope this is enough to unblock you.

@sdufel
Copy link
Contributor Author

sdufel commented Sep 18, 2024

Great, thanks for the speedy attention!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants