Consistency of delay with errors and completes

[voliva]

I've recently ran into a small issue with delay operator: It doesn't work as I initially expected with completions.

In my case I would've expected:

const completeAfterOneSecond$ = EMPTY.pipe(
  delay(1000)
)

to complete after one second. But it completes synchronously.

I know this can be written using timer + ignoreElements, but it feels inconsistent. Take this example:

const completeAfterOneSecond$ = of("whatever").pipe(
  delay(1000),
  ignoreElements()
)

this one it does complete after 1 second. If the source emits any value before completing, then it waits the delay, emits the value and completes.

I've prepared a sandbox with a few examples, and I've also seen there's something which I think it could lead to unexpected behaviour, if the stream errors.

const errorAfterOneSecond$ = throwError("boom").pipe(
  delay(1000)
); // Errors synchronously

I kind of understand the reasoning of "the stream has blown up, you need to deal with it" for this one. But, this example:

concat(
  [1,2,3,4,5],
  throwError("boom")
).pipe(
  delay(1000)
);

Also errors synchronously without emitting any value, even though the values from (1..5) were emitted from the source, which I think it can be raised as unexpected.

Wouldn't it make more sense if it was consistent with all kinds of notifications (next, error, complete)? If I can raise this as a bug/feature request, should this be done for 8.x or can it be raised for 7.x?

[kwonoj]

This is dupe of #5858 , as shared it explicitly states delay only works with source emits while your example is already completed | terminated synchronous source.

[voliva]

I'm sorry maybe I didn't express myself clearly, but I didn't raise this discussion as a bug report - But rather as a discussion whether it would make more sense if it also delayed completions and errors so that it had a more consistent behaviour.

In a way I feel like the examples in the original post behave differently as one would initially expect - I was specially surprised by the one with concat + throwError.

[josepot]

I also think that it would be nice to have the option of being able to apply the delay to completion and errors.

A way to accomplish that -without triggering breaking changes- would be to add an overload to delay that took a configuration object as the first argument, e.g:

delay({
  due: 1000,
  next: true,
  complete: true,
})

Meaning that something like delay(1000) would be sugar for: delay({ due: 1000 }).

The signature of this configuration object could be something like:

interface DelayConfig {
  due: number | Date,
  next?: boolean,
  complete?: boolean,
  error?: boolean,
}

And by default the value of next would be true, and the default values of complete/error would be false.

I wouldn't mind sending a PR implementing this behavior if the core team agrees with this idea.

[backbone87]

ref #6465 which describes related behaviors in other operators