Better handling of failed parses

[Connoropolous]

We had this in the last versions too, the pre 1.0.0 versions, as an issue... what if, when there's an error, it tries again but this time spells out where the error is with serde path to error?

async-stripe/async-stripe-client-core/src/stripe_request.rs

Line 154 in 3c86313

from_str(str).map_err(|_| Err::deserialize_err("error deserializing request data"))

[arlyon]

The issue is that stamping out serde types for thousands of types has a very high cost both in terms of the code size and compile times. Not to mention people running out of memory on CI and a host of other issues.

#77

The solution, miniserde, uses monomorphisation to avoid this but with a fatal flaw which you discovered; no information about where an issue occurred.

My suggestion is enable the serde feature for the event you'd like to parse, write a test with serde_path_to_error and see what the issue is.

I would be very happy to receive a PR which, in the event that the serde feature were enabled on webhooks, would do as described and enter a new branch in the event of failure that would highlight the issue. I opted not to log the data by default in case the event contains sensitive information, however another option is I build a wasm build and host it somewhere with serde enabled which lets you paste an event and check for parsing issues.

[Connoropolous]

Thanks!

I need to identify what to do in the situation I'm in.

This struct: https://github.com/arlyon/async-stripe/blob/master/generated/async-stripe-shared/src/balance_transaction_source.rs#L6
is missing 'balance_transfer' which appears to legit exist in the data delivered by stripe api, even though its not in the stripe openapi spec.

Best way to resolve this?

[arlyon]

You could open a ticket with stripe https://github.com/stripe/openapi. I will see if I can get around #723 some time soon which will help