Debugging an issue with switchMap led me to reviewing the OperatorSwitch code. I think it might be wrong in its approach on backpressure (at least when used as switchMap), but before attempting code wanted to discuss conceptually. (Note that I have not considered switchOnNext or switchOnEmpty where the current approach may be fine.)
Right now it appears to pass-thru the requestN value from downstream to the upstream. This doesn't seem correct for a switchMap case. Instead I think it should be have as follows:
- request 2 on initial subscribe
- map starts on first received onNext
- downstream
request(n) is propagated to the inner Observable
- onNext invoked a second time with new Observable
- request(1) upwards to allow the upstream to send a new Observable
- propagate remaining
request(n) from downstream to the new inner
In other words, quite similar to how concatMap works for maintaining the request(n) value across inner Observables, except that it unsubscribes the previous inner on receiving a new Observable.
Debugging an issue with
switchMapled me to reviewing theOperatorSwitchcode. I think it might be wrong in its approach on backpressure (at least when used asswitchMap), but before attempting code wanted to discuss conceptually. (Note that I have not consideredswitchOnNextorswitchOnEmptywhere the current approach may be fine.)Right now it appears to pass-thru the
requestNvalue from downstream to the upstream. This doesn't seem correct for aswitchMapcase. Instead I think it should be have as follows:request(n)is propagated to the inner Observablerequest(n)from downstream to the new innerIn other words, quite similar to how
concatMapworks for maintaining therequest(n)value across inner Observables, except that it unsubscribes the previous inner on receiving a new Observable.