Failing effect crash on iOS 13 when using flatMap + zip + catch

[lukeredpath]

Describe the bug
The fix in #483 fixes the combination of .retry() and .catch() however it was not fixing the crash in my app which I managed to eventually narrow down to a combination of .flatMap, .zip and .catch resulting in the same crash:

2021-04-08 17:14:29.749390+0100 xctest[41980:3533660] Fatal error: Unexpected state: received completion but do not have subscription: file /Library/Caches/com.apple.xbs/Sources/PubSub_Sim/PubSub-134.102/Combine/Source/Catch.swift, line 248

I can only reproduce this on iOS 13. iOS 14 does not have this problem (leading me to think there's a bug in that version of Combine). I have not tried other platform targets.

To Reproduce
A crashing test that reproduces this can be found here:
main...lukeredpath:combine-ios13-fail-catch-crash

Copying here for posterity:

  func testEffectErrorCrash_WithFlatMapZip() {
    let expectation = self.expectation(description: "Complete")

    Effect<Int, NSError>(error: NSError(domain: "", code: 1))
      .flatMap { _ in Effect(value: 123) }
      .zip(Effect<Int, NSError>(value: 456))
      .catch { _ in Fail(error: NSError(domain: "", code: 1)) }
      .sink(
        receiveCompletion: { _ in expectation.fulfill() },
        receiveValue: { _ in XCTFail("Effect should fail") }
      )
      .store(in: &cancellables)

    self.wait(for: [expectation], timeout: 0)
  }

Expected behavior
Ideally this should not crash. In practice this seems to mainly effect our app tests where we are more likely to return a failing effect e.g. from a mock dependency. My only current workaround is to skip the crashing test on iOS 13.

Environment

• Xcode 12.4
• OS: iOS 13.7 simulator

[mbrandonw]

Here's one workaround, but might be best as a helper for your tests since it's definitely a hack:

  public init(error: Failure) {
    self.init(
      Deferred {
        Future { callback in
          DispatchQueue.main.async {
            callback(.failure(error))
          }
        }
      }
    )
  }

You will need to introduce an expectation to wait a small amount of time to get over that thread hop though.

Mind if I convert this to a discussion since it's an Apple bug and not a TCA bug? Maybe others have ideas on better workarounds.

[lukeredpath]

Sure, no problem.

I suspected a queue hop would fix it, I'd really like to try and avoid it if I can though as its only affecting one of our tests right now and I'd rather just skip the test on iOS 13 (the failing effect is coming out of our API client mock with stubbed requests so changing that would have a much bigger knock-on effect).