startWith + combine + combine with itself results in first emitted value ignored

[frangio]

Here's a simplified example of the bug:

const a$ = xs.of('bye').startWith('hello')
const b$ = xs.of('world')

const c$ = xs.combine(a$, b$).map(([a, b]) => a + ' ' + b)

xs.combine(c$, c$).debug(console.log).addListener({
  next: () => {},
  error: () => {},
  complete: () => {},
})

Note that c$ is combined with itself. This also happens if c$ is combined with a stream derived from itself.

This should print

["hello world", "hello world"]
["bye world", "bye world"]

Instead, it only prints the second line.

This is especially bad if a$ is xs.never().startWith('hello'), in which case nothing ever prints... or instead of xs.never() a Cycle.js DOM event stream from an element which isn't in the DOM yet! This exactly led to the app never starting in my case.

[staltz]

Thanks for reporting. Here's a smaller example of the bug:

const a$ = xs.of('bye').startWith('hello')
const b$ = xs.of('world')

const c$ = xs.combine(a$, b$).map(([a, b]) => a + ' ' + b)

c$.addListener({
  next: (x) => { console.log(x) },
  error: () => {},
  complete: () => {},
})

It definitely has to do with race condition and synchronous emissions, since xs.combine(b$, a$) behaves differently than xs.combine(a$, b$).

[staltz]

This issue also happens in most.js cujojs/most#414 and RxJS ReactiveX/rxjs#2414

[frangio]

That's interesting. What about what I mentioned in the last paragraph? How does that compare to the other stream libraries? That's the real deal breaker I think, because at least in the case of Cycle.js it causes a sort of deadlock that prevents an app from starting.

[staltz]

This is especially bad if a$ is xs.never().startWith('hello'), in which case nothing ever prints... or instead of xs.never() a Cycle.js DOM event stream from an element which isn't in the DOM yet! This exactly led to the app never starting in my case.

This case didn't happen with me with this snippet

const a$ = xs.never().startWith('hello')
const b$ = xs.of('world')

const c$ = xs.combine(a$, b$).map(([a, b]) => a + ' ' + b)

c$.addListener({
  next: (x) => { console.log(x) },
  error: () => {},
  complete: () => {},
})

Notice that your original example had xs.combine(c$, c$) which is quite strange and probably the source of the problem for never().startWith()

[staltz]

I'll repeat what Brian said about this case in most.js cujojs/most#414 (comment), which I fully agree with:

I'm ok with saying that the current behavior is correct for 1.x. Like both trxcllnt and TylorS have pointed out, values from an array (or other synchronously available data structure) are not really events, they're simply data, and as such they have no time dimension. There is an implicit time imposed on them based on the instant of observation, but it's artificial. They're simultaneous, but indexed.

For now, I think we can say that when given a bunch of simultaneous indexed values, combine() observes the last ("last" as in index order) one.

What I don't like is that the API allows a user to do get into this situation in the first place. The only way to prevent it currently is to tell users not to do it. Let's think about ways we can prevent it in the future.

[frangio]

I'm not sure the problem here is about simultaneity of events. I see this as an issue about startWith.

The most.js code analogous to yours does not exhibit the bug for which I created this issue.

const a$ = most.of('bye').startWith('hello')
const b$ = most.of('world')

const c$ = most.combine((a, b) => a + ' ' + b, a$, b$)

c$.forEach(console.log)

prints as expected:

hello world
bye world

I feel like this is an issue about the equivalence of xs.from(array).startWith(value) with xs.from([value, ...array]). I don't think these should be equivalent, as an event added via startWith should come before the rest of the stream, so it shouldn't be simultaneous with any of its events.