Skip to content

fix: report the right number of dropped bytes#927

Open
KowalskiThomas wants to merge 4 commits intomasterfrom
kowalski/fix-report-the-right-number-of-dropped-bytes
Open

fix: report the right number of dropped bytes#927
KowalskiThomas wants to merge 4 commits intomasterfrom
kowalski/fix-report-the-right-number-of-dropped-bytes

Conversation

@KowalskiThomas
Copy link
Copy Markdown
Contributor

@KowalskiThomas KowalskiThomas commented Mar 25, 2026

What is this?

This PR updates the dropped bytes reporting logic to actually report the number of bytes dropped and not the number of packets dropped.

@KowalskiThomas KowalskiThomas added the changelog/Fixed Fixed features results into a bug fix version bump label Mar 25, 2026
@KowalskiThomas KowalskiThomas marked this pull request as ready for review March 25, 2026 20:48
@KowalskiThomas KowalskiThomas requested review from a team as code owners March 25, 2026 20:48
except queue.Full:
self.packets_dropped_queue += 1
self.bytes_dropped_queue += 1
self.bytes_dropped_queue += len(packet) + 1
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm curious, why add 1 to the packet length?

Also, would it be possible to add a test for this?

Copy link
Copy Markdown
Contributor Author

@KowalskiThomas KowalskiThomas Mar 26, 2026

Choose a reason for hiding this comment

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

why add 1 to the packet length?

I believe the packet length would be the size of the string in characters + one null byte the new line we add in the message (sorry I got things mixed up here), right? (If not then we shouldn't add 1)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

would it be possible to add a test for this?

Sure :)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Just added a test

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Non-ascii characters may not be supported in metric names, but they are supported in tags, and this is being used. If we say that we count bytes, we should count bytes.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Interesting, that's a good point, and to be honest I didn't know about that. The docs aren't super clear about it I think 😅

May contain alphanumerics, underscores, minuses, colons, periods, and slashes. Other characters are converted to underscores.
...
Tags can be up to 200 characters long (including both key and value) and support Unicode. Additional characters beyond this limit are truncated.

Which I guess means you can submit Unicode characters in tags but they'll be converted to underscores if they're not part of the supported character classes?

Anyway, I'll update the way we compute the value.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Just updated it, please have another look 🙇

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Which I guess means you can submit Unicode characters in tags but they'll be converted to underscores if they're not part of the supported character classes?

No, we definitely support non-ascii text in tags in backend. Coincidentally, docs are being updated to make this more explicit.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Sounds good, noted.

Copy link
Copy Markdown

@Kaycell Kaycell left a comment

Choose a reason for hiding this comment

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

No issue on the principle but need a test to clarify behavior :)

except queue.Full:
self.packets_dropped_queue += 1
self.bytes_dropped_queue += 1
self.bytes_dropped_queue += len(packet) + 1
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Kaycell
Kaycell previously approved these changes Mar 26, 2026
@KowalskiThomas KowalskiThomas force-pushed the kowalski/fix-report-the-right-number-of-dropped-bytes branch from 7e16b3c to 3edfc4d Compare March 27, 2026 10:02
@KowalskiThomas KowalskiThomas requested a review from vickenty March 27, 2026 12:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/Fixed Fixed features results into a bug fix version bump

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants