Skip to content

Conversation

@ThomasBrady
Copy link

@ThomasBrady ThomasBrady commented Jul 30, 2025

Preserves the types of fields in records by using a custom decoder with UseLooseInterfaceDecoding(false) set.

https://app.shortcut.com/chronosphere/story/143811/number-type-loss-in-calyptia-plugin-messagepack-decoding

@ThomasBrady ThomasBrady requested a review from a team as a code owner July 30, 2025 17:06
@ThomasBrady ThomasBrady changed the title bug: Preserve types when decoding records [sc-143811] fix: Preserve types when decoding records [sc-143811] Jul 30, 2025
}

return out, fmt.Errorf("msgpack unmarshal event time: %w", err)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated to you but i dont understand the code above this at all. in the event of an error, it looks like we do a lot of stuff w/o any side effects and then return an error in all paths.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm yeah that seems like a bug. It tries to decode the time, then has a couple fallback ways of decoding it but returns an error regardless of if the fallbacks succeed.

Comment on lines +523 to +530
// Create a decoder that preserves number types (int64 vs float64)
// instead of converting all numbers to float64 like the default msgpack.Unmarshal
recordDecoder := msgpack.NewDecoder(bytes.NewReader(entry[1]))
// Configure decoder to preserve exact number types instead of converting to float64
recordDecoder.UseLooseInterfaceDecoding(false)

var record map[string]any
if err := msgpack.Unmarshal(entry[1], &record); err != nil {
if err := recordDecoder.Decode(&record); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this only for Go output plugins?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm yeah upon further investigation this isn't the cause of the behavior I'm seeing when testing the json processing as http_sink doesn't use this. May as well fix this here tho.

Copy link
Contributor

@stoksc stoksc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm. but as far as i know, output plugins have bigger issues than this and i dont think fixing it is pressing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants