[It](https://github.com/jamesmunns/cobs.rs/pull/39) is related to https://github.com/jamesmunns/cobs.rs/issues/27 . perhaps, all that is necessary is to check the length of input data stream to code, and skip decode calls if it is 0? @barafael good to hear that pre-checking the length works for you! Just wanted to make you aware of a bunch of stuff that I've written that help with things like this, in case you haven't seen them before. I've written them because they handle common pitfalls like this: * The postcard crate has a "cobs accumulator": https://docs.rs/postcard/latest/postcard/accumulator/struct.CobsAccumulator.html, useful for when "one usb frame != one postcard message", because multiple messages are in one packet, or one message is larger than one packet. Since you are using USB-serial, this **WILL** eventually happen, since usb-serial has no concept of "frames", which is why we use cobs! This would have done the "don't try to decode a zero length message" check for you. * The postcard-rpc crate is really specifically built around this pattern of "request and response", and can help you with dispatching these messages. postcard-rpc CAN work over usb-serial, but it can also work over "raw" usb, which is going to be much more efficient in nearly every case. I highly recommend postcard-rpc if your use case is a command/data link to a single device over USB. * I'm currently working on ergot, which is a more flexible version of what postcard-rpc is. It allows more than a single device link (e.g. a whole "network"), and gives you sockets instead of a more "callback" like operation. It also works over USB, but it's much more experimental than postcard-rpc for now: https://docs.rs/ergot/latest/ergot/book/index.html If you know about all of these, and choose not to use them, that's fine! But I've built them specifically to avoid little pitfalls like this :)