[docs] Is the order of merge guaranteed?
See original GitHub issueWhile answering a question I actually came across the thought of whether the order of a merge
d observable is guaranteed if the input observables emit synchronously. Consider this example:
Observable.merge(Observable.of(1), Observable.of(2))
.subscribe(console.log);
Is this guaranteed to emit 1
and then 2
or could it also be the other way around? I’m not so much asking about the current implementation but about the contract the merge
operator gives me.
Whatever the answer, it should probably be documented. The current docs don’t seem to mention the order at all.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:10 (7 by maintainers)
Top Results From Across the Web
SQL Merge SOURCE order and OUTPUT order - Stack Overflow
The documentation on OUTPUT explicitly states: There is no guarantee that the order in which the changes are applied to the table and...
Read more >Does MERGE statement preserve order? (Slowly Changing ...
However, as far as I can tell, there is no guarantee that the data will be processed (MERGED) according to the order in...
Read more >Merge Orders - WooCommerce
The Merge Orders extension allows you to merge orders, combining the line items from multiple orders into one to process and ship them...
Read more >Merge requests API - GitLab Docs
Returns merge requests which have been approved by all the users with the given id , with a maximum of 5. None returns...
Read more >Using the Merge Operator
This is important because the merge operation waits for data on all input ports, in order to guarantee that the output is correctly...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
This seems like the behavior of the recursive scheduler. Can you read https://staltz.com/primer-on-rxjs-schedulers.html and see if that answers most of your concerns?
Closing in favor of an issue on the docs repository: https://github.com/ReactiveX/rxjs-docs/issues/241