Graceful error handling?

[luciascarlet]

Codable's default behaviour is to throw a DecodingError if it doesn't know how to decode something, which is fine if you are dealing with data that is always guaranteed be a certain shape, but this cannot be guaranteed for Bluesky/ATProto at the moment as it is rapidly changing. While the library can of course be updated with newer versions of the lexicon, I don't believe that this is an ideal solution in the long term, as apps built against older versions of the library for an earlier lexicon will completely cease to work.

I have been using this library to work on a Bluesky client, and I ran into an issue with logging in because the didDoc is no longer a union, but a new object that is not represented by the lexicon. Technically, the didDoc is not strictly essential for a Bluesky client to work, and it is in fact represented as optional in the generated lexicons. However, because decoding of this one object fails, sending a creatingSession request fails completely.

I understand that due to the way Swift's Codable works it would be tricky to work around this and introduce a more graceful way of handling decoding errors, but I strongly propose looking into this if possible, as it would make this library a lot more resilient if Bluesky's API changes.

Here I have attached a screenshot of the current didDoc response, the representation of didDoc in Lexicons.generated.swift, and the resulting error message when attempting to send a createSession request.

I'd love to hear back about this and whether it would be feasible to implement; this library has so far been very helpful for me, and I really lack the experience with code generation needed to try implementing this on my own

Edit: I ran the the update lexicon GitHub action on a fork and I receive the same error when sending a CreateSession request there, so I'm not sure if the official definition of the lexicon has not been updated yet or something, or whether decoding fails elsewhere.

Edit 2: Looking into this further, it seems like that union cannot deal with anything that doesn't have a defined $type field and is not otherwise validated. This is beyond the scope of this specific issue at this point, but graceful error handling would remain beneficial here.