Crash on some Apple Watch models

[eimantas]

I have a state that does periodic requests to an endpoint (through environment) and depending on the response it produces on of two actions: success or retry. The retry action is returned in a throttled effect that crashes upon firing:

Effect(value: .retryRequest)
  .throttle(
    id: retryId, 
    for: 5, // this is where the crash is marked
    scheduler: env.scheduler, 
    latest: true
  )

The crash message is EXC_BREAKPOINT with underlined 5 in my case. Given it crashes only on some AW models, I can't reproduce it consistently. Can any of you provide me with ideas on how to work around this crash?

[iampatbrown]

Can you provide any more info about the action/crash? It could be a threading issue? Adding .receive(on: .main) to your Effect may help.

[eimantas]

This is how a crash looks like in Xcode:

The .receive(on: env.scheduler) (which is .main in .live environment) is in the Effect returned from previous action.

environment.doRequest()
.receive(on: env.scheduler)
.catchToEffect({ result in
  if result.success {
    return effectWithRetry // the effect above screenshot
  } else {
    return .success
  }
})

[eimantas]

I managed to fix the crash, but now I don't have defer/throttle behaviour at all. Here's how the effect looks like:

        return Effect(value: (param01, param02))
            .deferred(for: .seconds(5), scheduler: env.scheduler)
            .flatMap(env.doRequest)
            .receive(on: env.scheduler)
            .eraseToEffect()

and I still see that the action is being called every 2 or 3 seconds (that's how long it takes to doRequest with param01 and param02.

I am completely baffled :( is it something that I don't understand about how schedulers work?

[eimantas]

Another thing — the devices/simulators that had this code running perform proper 5 second delays between running the requests.

I would be willing to write this down to some cosmic radiation bug if it was only one device. But there are a few with no apparent common marks (apart from them being Apple watches).

[iampatbrown]

I don't fully understand your use case but was it originally set up where a retryRequest could create another retryRequest? If a retryRequest hadn't responded in the given timeframe was it getting cancelled?
Also, I remember someone at some point having an issue trying to schedule tasks in the background. It was just a vanilla SwiftUI thing though. It was like the scheduler would stop triggering or get out of sync... especially when the View wasn't the main focus. Not sure if it's related, but it could be something that is more likely to occur on watchOS.
Someone else might be able to help you out more though.