-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Demonstrate possible issue #37
base: master
Are you sure you want to change the base?
Conversation
Hi @jkopanski. Thanks for describing your use case and for taking the time to create a test case to show it. I'm not sure I fully understood, though. Do you think you could try to find a simplest-possible example of what you think the issue is? Thanks! |
I've just ran into exactly the same issue. However my case is slightly different.
|
Here're some marbles:
Legend: A - hot source, H - held source, S1 - first subscription (^ - run, ! - dispose), R1 - events in the first subscriber, S2 - second subscription, R2 - events in the second subscriber. Here you can see that 2nd subscriber runs the stream after the first disposal and it should receive both events |
Hey @briancavalier, thanks for your patience. I'll try and possibly simplify testcase but I'm bit swamped at work. For now we copied hold and perform only a value check before scheduling flush. |
Same for me :) |
However that breaks one of original test cases, so I am not sure if this comibnator was intended to be used that way |
@jkopanski This happens because Line 30 in d57c408
Then first run is made by p0 's collect (Note that the source is diposed by take(1) ): Lines 32 to 33 in d57c408
The second run is then made by p1 's collect 5ms after:Lines 54 to 56 in d57c408
hold sends the last remembered value from the first run "0" and then reruns the source resulting in the [0, 0, 1, 2] .
Here're some marbles describing the failing test:
I'm not exactly sure what should be the correct behavior for holding cold sources but I think this (which breaks the test) is definitely more intuitive for me and it reflects the description of the package: @briancavalier What do you think? |
Hello and thank you for awesome library!
Recently I came across a use case that I thought was good fit for
hold
. Unfortunately it didn't work as expected. Before opening up the issue I thought that maybe I'll clarify what I do and what outcome I expect with a minimal test case.I maintain an collection of streams (array in the example). Elements will come and go depending on the user interactions. That array is later combined to produce final result. I thought that each
combine
call is like creating a now observer for the held stream, however previous value isn't provided.Is this how
hold
is suppose to work? Or did I actually found some issue here?