mattsse
Properly handle invalid messages
As the CDP changes, messages can become different from the definition. As long as there is no breaking change, this will be fine. Sometimes though those messages will have breaking changes.
In this case we want to be able to handle them properly. Before this change the user had to add clause to handle CdpError::Serde. With this change we introduce CdpError::InvalidMessage. This is already clearer on the intent.
I reverted #197 since it is not the job of the connection to decide what to do with those errors. Instead I added a configuration on the handler to avoid those errors from surfacing (instead they are logged). If a user wishes to handle those errors themselves, they can disable that config.
I added a test to ensure that the untagged union problem of serde doesn't affect us.
I also checked the proposal to add a new CdpEvent variant to handle those malformed events, but like I mentioned on the PR this is not viable because it would require the user to add a custom event listener for all event ids.
Closes #206 Closes #207 Closes #243
@mattsse sorry to bug you but can you take a look. I dont want the PR to go stale
Hi @mattsse I hope to see that there are bugs and that it stops working.
I actually have maintainer status now, I will try to find some time to do a release
I actually have maintainer status now, I will try to find some time to do a release
I’ve been waiting nearly a year for this fix to be merged #243 😄 - really glad to see progress on it at last. I was starting to wonder if the project had been abandoned. It’s great to see you on board as a maintainer now!
It is not @ling0x, just finding time to work on it is hard :S I need to do some fixes anyway on the fetcher to allow download of the "new" chrome headless thing.