Reentrancy anomaly detected when using KingfisherManager about rxkingfisher HOT 6 CLOSED

Ah okay, I think I figured out what's going on here. If a task is cancelled, it appears that the error block is called twice in the same run loop – once for the request timing out, and once for the task being cancelled. I think the right approach here to only send error states when the error is not the task being cancelled (for this use case I don't think we would ever want that.)

I don't think there are any downsides to filtering out task cancelled errors, but maybe someone can back me up on that. I'll put up a quick PR with a fix and we can use that to have further discussion if that's helpful!

from rxkingfisher.

I think the issue isn't in the method, it's outside of it. Can you show the method that invoked getImage?

from rxkingfisher.

Hi @freak4pc , thanks for answering me back.

The code above, belongs to the ImageInteractor class, which handles the image requests.
I'm creating the observable, without subscribing, using the method getImage:

            if let imagePath = $0.categoryLink?.image {
                iconImage = imageInteractor.getImage(with: imagePath)
            }
            return IncidentViewModelItem(incidentId: $0.id,
                                         iconImage: iconImage,
                                         title: $0.name,
                                         stages: [])

And then, I'm setting up a tableview cell with the object IncidentViewModelItem I created.
In the tableview cell, I'm subscribing: (I put only the code that relates to Rx)

internal var disposeBag = DisposeBag()

override func prepareForReuse() {
        super.prepareForReuse()
        disposeBag = DisposeBag() 
}

func setup(viewModel: IncidentViewModelItem) {
        self.viewModel = viewModel
        
        viewModel.iconImage?
            .subscribeOn(ConcurrentDispatchQueueScheduler(qos: .background))
            .observeOn(MainScheduler.asyncInstance)
            .subscribe(onSuccess: { [weak self] (image) in
                self?.iconImageView.image = image
            }).disposed(by: disposeBag)
}

from rxkingfisher.

Unfortunately I don't have the full picture, yet.
But - the fact it only happens for token refreshals probably means the reentraancy is caused by the fact getImage invokes a token refresh which invokes getImage again, which is sort of a reentrancy, but it's really hard to say.

Regardless, this isn't an issue with RxKingfisher as far as I can tell since it works on the "happy path", so it's just some issue with scheduling / other code that you have there which I can't see

from rxkingfisher.

I'm not using this library but have an ~identical implementation wrapping KingfisherManager and downloading an image. I found that the task getting cancelled causes a re-entrancy anomaly. I've debugged a few re-entrancy anomalies before but I'm struggling to figure out why cancelling the task does it here. I'm not sure if it's the same thing @PabloDomine is experiencing but figured I'd add my info here just in case it helps.

Commenting out the task?.cancel() in the Disposables.create { } block fixes the issue, but is not ideal because then the resource is retrieved even when the subscription has been disposed.

In the stack, I notice that the error block had been called several frames before task.cancel() gets called, which must be what's causing the unwanted cycle.

from rxkingfisher.

Thank you for stepping in @eliotfowler and sorry for the radio silence.
Unfortunately, I cannot test this issue under the same exact conditions anymore, since the API has changed and it's not longer returning vectorial images, but regular .jpg's.
If I have time, I will try to try this again in a different environment.
Thank you again @freak4pc and @eliotfowler!

from rxkingfisher.