Do the TelemetryAPI records support JSON record fields?

[mheffner]

According to the TelemetryAPI docs, if you're using a more recent schema version than "2022-12-13", the record field of function and extension logs may be a string OR a JSON record.

From the code it would appear that these only support the string records. Do these need to be updated to something like serde_json::Value to handle both cases?

aws-lambda-rust-runtime/lambda-extension/src/telemetry.rs

Lines 25 to 30 in f69280e

	pub enum LambdaTelemetryRecord {
	/// Function log records
	Function(String),
	/// Extension log records
	Extension(String),

Thanks!

[jlizen]

Looks like you're right! Feel free to modify this issue into a feature request, or take a stab at implementing it!

One way to deal with this might be to encode it at the type level via a generic (or more likely a separate struct, since adding a generic to LambdaTelemetryRecord would cause semver breakage). And then the caller could just specify that in their handler if they want to receive processed JSON. The downside of that approach though is that it would be effectively hardcoding a choice around log format, whereas advanced logging controls are designed to be changeable in console, etc. I guess probably the caller could write two different handlers and choose between them based on the same ENV, but it's all pretty klunky.

Maybe it would be better to newtype both of the inner record types and offer a .json() method on them that lazily attempts to deserialize if invoked? That keeps the handler signatures simple but still lets the caller apply context around whether a given record format is set or not?

You could MAYBE hack something together with a new typed inner enum that has an internally tagged variant for serde that uses one of the known json field names, and a #[serde(other)] tag on the plain variant? Except that would force callers to match on them all the time, and also that would be semver breakage.

I think probably .json() would be simplest to implement + less terrible to maintain / not too unergonomic for callers...?

Just sharing my perspective! (Not a maintainer / not offering to implement this)

[mheffner]

That all makes sense @jlizen. Yeah, we decided to go with a quick fix to swap these for serde_json::Value types. Obviously, we weren't trying to maintain semver compatibility and it pushes the match handling onto the user. I'm happy to open a PR with that, but as you allude to, I think this is probably a decision for the maintainers as to how they'd want to proceed.

[jlizen]

cc @bnusunny for perspective on this one... my knee jerk is, probably not good to cut to modeling a serde_json::Value type, even across a breaking semver boundary. Seems like a future semver hazard and anyway it's trivial for callers to choose to parse the String into JSON themselves. If we did want to do it, we also probably would want to make it a RawValue to avoid extra cost if caller is just passing it through without interacting with fields.

That said I do think a .json() method (or if this is a strongly typed schema, a .record() API that parses into it) might be good as a middle ground to help with ergonomics.