Unhandled URC causes URC to stop working

[dragonnn]

This is partly connected to #179
If I don't add +CREG Urc to my URC enum and the modem sends the URC any URC happening after it isn't handled, I suspect because the first one is still in the buffer?
Even when the parsing of response and same response is handled fine I feel like URC should have an option to recover from stuff it gets that isn't defined in the URC enum.

I am really sorry about making the last 3 issue on your project :/, hope you are not yet annoyed by me 😅

[MathiasKoch]

Huh, interesting find. I have disabled the URCs for those 3 that fails to distinguish the URC from response, but even with them enabled it should just discard them.

I am SUPER happy you are finding, and reporting, these bugs! We are using this in production on thousands of IoT devices, so any improvements in stability is highly appreciated.

Even better with PRs fixing them, so I am just super grateful 🙏

[dragonnn]

Huh, interesting find. I have disabled the URCs for those 3 that fails to distinguish the URC from response, but even with them enabled it should just discard them.

Not sure if you did understand it right, it doesn't discard them when they are not present in the Urc enum.
Example:

#[derive(Clone, AtatUrc, Format)]
pub enum Urc {
    #[at_urc("APP RDY")]
    AppReady,
    //#[at_urc("+CREG")]
    //Creg,
    #[at_urc("+CMTI")]
    NewMessage(NewMessage),

    #[at_urc("+QIOPEN")]
    ChannelOpen(ChannelOpen),

    #[at_urc("+QIURC")]
    Action(Action),
}

Creg Urc is commented out, the modem sends a few CREG URC because the base station has changed: +CREG: 1,"E18C","43A460A",8 after that I send a sms to them modem with does send +CMTI but that isn't parsed in that case, no new URC goes through after the unhandled CREG URC

[MathiasKoch]

Yeah, I understood the issue, I was meerly offering a reason for why we have not come across this ourselves, as well as the intended behavior, that obviously doesn't work :)