Resolve waitForFirstResult on the initial query result, not the seed emission - #2541
Merged
Conversation
Observe() built its subject before running the initial query, so the collection variants handed every subscriber a BehaviorSubject seeded with an empty collection. A one-shot read with waitForFirstResult=true resolved on that seed and returned an empty payload with isReady: true - a confident, well-formed answer that was indistinguishable from a genuinely empty read model, and never resolved by waiting longer. Back the subject with a single-value ReplaySubject instead: nothing is emitted until the initial query completes, and the latest emission is still replayed so a subscriber arriving after that query sees its result. This also closes the same gap on the single-document and joined variants, whose plain Subject silently dropped the initial emission for a late subscriber.
Cover the three guarantees the seed-emission fix rests on: nothing is emitted before the initial query completes, the first emission carries that query's documents, and a late subscriber gets them replayed. Grant Cratis.Arc.MongoDB.Specs access to Arc.Core internals so the observe specs can configure Internals.ServiceProvider, matching how the EF Core observe specs are wired.
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
| public class and_the_initial_query_has_not_completed : given.an_observed_collection | ||
| { | ||
| ISubject<IEnumerable<ObservedDocument>> _subject; | ||
| List<IEnumerable<ObservedDocument>> _emissions = []; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A one-shot HTTP read of a collection-backed observable query with
waitForFirstResult=truereturned the observable's empty seed value withisReady: true, deterministically and regardless of the timeout. Because the payload was a well-formed empty collection and the result reported itself as ready, a caller had no way to tell it apart from a genuinely empty read model. Anything that cannot hold a stream open was affected: cURL and scripted reads, readiness probes, integration specs, and server-to-server fetches.Fixed
waitForFirstResult=trueon a MongoDB collection-backed observable query now resolves on the initial query result instead of the empty seed emission that preceded it (waitForFirstResult on a collection-backed observable query returns the empty seed emission as isReady #2535)