Show transceiver errors in wicket UI

[bnaecker]

• Make all transceiver data results rather than options
• Report errors in the wicket UI for each piece of data we failed to read
• Fixes wicket screen should show present but faulted or unreadable transceivers #8110

[bnaecker]

I ran a quick test of this by manually inserting a failed transceiver on the wicketd side. It shows up like so in the wicket UI:

There's some duplication of the errors in different lines because it's derived from the same request to the SP for the transceiver state, but I think it's OK. We could reorg the UI more significantly to reduce that if it's a big eyesore.

[bnaecker]

Not sure the best way to handle the OpenAPI linting issues here. I really want a Result, but that ends up with a terrible name in the spec. Hand-rolling enums that are the same, with Ok(T) and Err(String) variants works, but is also kind of annoying for developers.

[jgallagher]

Not sure the best way to handle the OpenAPI linting issues here. I really want a Result, but that ends up with a terrible name in the spec. Hand-rolling enums that are the same, with Ok(T) and Err(String) variants works, but is also kind of annoying for developers.

Hmm. @davepacheco did this recently:

omicron/nexus/types/src/internal_api/views.rs

Lines 421 to 425 in 4067356

	#[serde(serialize_with = "serialize_snake_case_result")]
	#[schemars(
	schema_with = "SnakeCaseResult::<UpdateCompletedHow, String>::json_schema"
	)]
	pub result: Result<UpdateCompletedHow, String>,

with this helper:

omicron/nexus/types/src/internal_api/views.rs

Lines 471 to 493 in 4067356

	#[derive(JsonSchema, Serialize)]
	#[serde(rename = "Result{T}Or{E}")]
	#[serde(rename_all = "snake_case")]
	enum SnakeCaseResult<T, E> {
	Ok(T),
	Err(E),
	}
	fn serialize_snake_case_result<S, T, E>(
	value: &Result<T, E>,
	serializer: S,
	) -> Result<S::Ok, S::Error>
	where
	S: serde::Serializer,
	T: Serialize,
	E: Serialize,
	{
	match value {
	Ok(val) => SnakeCaseResult::Ok(val),
	Err(err) => SnakeCaseResult::Err(err),
	}
	.serialize(serializer)
	}

I wonder if it makes sense to move that somewhere more public and reuse it?

[bnaecker]

@jgallagher Thanks! I'm not sure how common it will be, but we definitely have an N of 2! @ahl had also mentioned to me a way to convince Progenitor to actually use an explicit Rust type when generating code. In this case, telling it to use the actual ::std::result::Result<T, E>. I'm not sure if that applies in Dave's case too, but it seems like it might.

[bnaecker]

Thanks for the tip @jgallagher. I've made us a small helper crate serde-helpers with that snake case workaround type. We can add more things as we need here. LMK if you have suggestions!

[bnaecker]

@ahl I've reworked the JSONSchema implementation to include the Rust type extension stuff. Doesn't look like we can use only the #[serde(with = "...")] at the use sites, we do still need that and the schemars(with = "...") as well. But would love another look at some point.