`debounceTime` emit right away when they reach the end of the observable they are debouncing

[shenlin192]

Bug Report

Current Behavior debounce and debounceTime emit right away when they reach the end of the observable they are debouncing as described in https://stackoverflow.com/a/55248103/5692151. This behavior is not described in the doc https://rxjs-dev.firebaseapp.com/api/operators/debounceTime

Reproduction

• REPL or Repo link: (https://rxviz.com/v/1o7AgWPJ)

Expected behavior If I understand correctly what the doc says, the observable should be emiited after a duration dueTime but not immediately.

Environment

• Runtime: Chrome 72
• RxJS version: Rxjs 6.2.1

[cartant]

IMO, this isn't a bug and is reasonable behaviour. The point of denouncing is to ensure notifications are not emitted too quickly. If the source completes, there will be no further notifications, so emitting the last notification right away is justifiable. I see no reason to wait out the delay.

[shenlin192]

Hello @cartant If so, won't it be nice to mention such behavior in the doc? :) It's not really obvious.

[cartant]

Yeah, if it's the expected behaviour, it should be mentioned in the docs.

Also, I guess it could be argued that it should be delayed in some circumstances. If the source emits a value shortly after an already-debounced value has been emitted from the operator, there are situations in which the subscriber could receive two notifications that are separated by an interval less than the specified duration.

[infacto]

This is counting and counting and counting ... never ends. Like interval(1000). Why? I checked the ngAfterViewChecked method. It stops after a few times. But when I use debounceTime (or another similar pipe) the log does not stop. Event with BehaviorSubject.

If this is by intended, what should I use to trigger only once after the specified time and end of emission?

[ivan-kleshnin]

IMO, this isn't a bug and is reasonable behaviour. The point of denouncing is to ensure notifications are not emitted too quickly. If the source completes, there will be no further notifications, so emitting the last notification right away is justifiable. I see no reason to wait out the delay.

Ok, but it's hard to justify why throttleTime behaves in the opposite way. It does delay a single value in trailing mode:

timer(2000)
  .pipe(
    RX.throttleTime(5000, undefined, {leading: false, trailing: true})
  )
  .subscribe(console.log) // single event after 7 seconds

vs

timer(2000)
  .pipe(
    RX.debounceTime(5000) // no leading/trailing config, docs describe trailing behavior
  )
  .subscribe(console.log) // single event after 2 seconds