Test gap tracking issue

[benalleng]

Beyond that, Earlier, on Monday's call, I mentioned I noticed a more few gaps in the tests and @nothingmuch pointed out.... In addition to what I've was working on, here's my list so far.... I think these could be split into 8-10is separate issues max... the one above being one of them

-@chavic

• Primitive validation coverage (Validate FFI primitive inputs + refresh bindings/tests #1263),
• Expose typed error variants for receiver errors in FFI bindings #1270
• Expose structured access to JsonReply error code and supported_versions in FFI #1271
• Add retryability and expiration metadata to FFI error types #1272
• Preserve OHTTP/HPKE error granularity in FFI bindings #1273
• Replace panic in HpkeError secp256k1 conversion with safe error handling #1274
• Expose replay error classification and variant data in FFI #1275
• Expose PSBT input error index in FFI error types #1276
• Expose detailed output substitution and input contribution error information in FFI #1277

[spacebear21]

While investigating the remaining issues tracked here, I realized that none of the FFI error wrappers implement expose the string representations properly downstream. It looks like we just need to add #[uniffi::export(Display)] to all FFI error objects: https://mozilla.github.io/uniffi-rs/0.30/types/uniffi_traits.html. We should also export any other supported traits that are implemented, i.e. Debug, Display, Eq, Ord and Hash.

I tried this with some existing error wrappers, before:

toString():   EncapsulationExceptionSenderPersistedException(Instance of 'EncapsulationException')

after:

toString():   EncapsulationExceptionSenderPersistedException(Directory response error: Unexpected response size 10, expected 8192 bytes)

This seems like low hanging fruit and a big easy win for implementers that should address these remaining issues at least partially.

[spacebear21]

This seems like low hanging fruit and a big easy win for implementers that should address these remaining issues at least partially.

#1485 addresses this

[spacebear21]

I'm going to close the rest of these issues as wontfix: I think #1272 and #1275 have a grain of truth to them (implementers should be able to tell between transient vs fatal errors), but I don't think the described approaches make sense. Also, IMO we should prioritize demonstrating proper fallback handling in the core library first to inform what actually needs to be exposed at the FFI layer.

@chavic The cognitive load of reviewing all of these bulk AI-generated submissions was quite high, next time I'd recommend focusing on one thing at a time and getting clarification before opening issues here.