Unhandled errors present while scrolling feed

[mormaer]

During internal testing of the 0.0.7 (23) build there have been reports of the following error message appearing repeatedly as the user scrolls their feed:

"Sorry, something unexpected happened. Please try again"

This is the default messaging in place when catching the .unexpected case from this request.

This suggests that the failure is occurring when we try to encode our request body (however loading posts is a GET with queries so unlikely!) or that we are failing to decode our response. This may point to differences between instances.

We need to find a way to easily reproduce this error so that we can locate the cause and fix.

[ShadowJonathan]

I should say the Lemmy API changes fairly often between minor versions, we're currently targeting 0.17.3, but it's possible some servers are still on older versions.

[mormaer]

@ShadowJonathan - do you know if they publish changes to the API anywhere? Or do we need to be digging for request/responses changes ourselves? 🫣

[ShadowJonathan]

The latter one, unfortunately

[EricBAndrews]

This is presumably going to be an ongoing problem--every time the Lemmy API updates, rollout across instances is going to be uneven. Do we want to try to build in multi-version API compatibility (weeps), or do we just go "yeah, it'll do that sometimes" and call it a day?

[tht7]

I think we should silently send a report somewhere and retry about 20 times before surfacing this annoying message at the very least

[mormaer]

I have an idea in my head for how we might reduce our risk to this.

I've said a few times that mapping the entire API response seems like unnecessary risk, but I can understand why we may want a 1-1 representation of the current version.

Once the rest of the the API is in I'd like to do two things next:

1. Split the API section out into a separate Swift Package.

2. Introduce a way for the views to define their own models but scoped within what is defined as the true API model

---

The first one opens the door to easily dropping the package into additional targets should we want to adopt watch support later...

Also I reckon we could then write a test suite/command line that used the package to easily tell us what models have broken, it could be used in conjunction with Jo's test environment to check as RCs are made available to give us as much of a heads up as possible to breaking changes.

Once we have an actual CI it could be automated for extra laziness.

The second point could be simplified by just letting the call-site of the request provide any (Decodable) model, which I believe we may do anyhow (as part of the model/repository layer which is planned), but I'd like to investigate how we can force those models to be scoped against the fully-mapped responses as it'd give us a bit of compiler safety when a breaking change is identified.

[tht7]

That sounds super cool but I think there already a package for that, so if we’re going this route why not just use that? Would definitely take a load off our backs

[mormaer]

There's already a Lemmy API package in Swift? 😱

[mormaer]

There's already a Lemmy API package in Swift? 😱

I see it now, released 2 weeks ago - we were already building the client we use in the app before that, as we did have a look-see first and there wasn't any around at that time.

I reckon if we have the types defined we would stick with our own client, it saves a dependency and means we can respond to breakages immediately within our own codebase as opposed to forking/raising PRs/waiting on an update before we can roll out a release?

[EricBAndrews]

Still present?

[EricBAndrews]

Closing as stale and also too vague