We _might_ choose to count message tags in the byte array and record that.
We'll need to be able to split the byte array into separate items without parsing anyway, for verification, so that code ...
We may want to consider a process for these. Something like this might work:
```
A "TODO" comment is permitted, but it must include a ticket ID.
We prefer the following format.
`@todo(###) des...
Please be careful with `.env`. In my opinion we should not even use such files, due to the very high incidence of secrets being exposed with `.env` files.
Environment variables (set via appropria...
I generally agree, but in rare instances it fixes the thoroughly excessive wrapping caused by the current spotless configuration.
When it saves multiple line wraps, and is not ambiguous, I would a...
@AlfredoG87 and @georgi-l95 we should pull this out of the current EPIC as it's not a Phase 1 goal.
Unclear if it need to be under a new EPIC or is fine as specified
Some confusion is evident in this description.
1. Blocks contain rounds, not the other way around
1. We will have roughly 1 block per second, which may contain arbitrary numbers of rounds (and that...
I like your approach, but I rather not use `.forEach` for concurrency and performance concerns. other than that, happy to implement this improvement, and YES! this is a bug waiting to happen, will...
I think we should be able to support them, is this something that can be done as part of a separate PR? as a follow-up? I don't think the refactor should have an even bigger scope for now.
My pr...
Good catch @ata-nas. These test parameters are intentionally very narrow. If you have to loosen them, I think it indicates there might be a bug. Let's collaborate to make sure the code is correct.
This is another example of PlatformSDK metrics API feature limitations, any other prometheus client would have a `increment(number)` overload that increments more than `1` at the time such counter....