Skip to content

Comments

feat: Add AsyncSequence.flatMapLatest operator#382

Draft
peterfriese wants to merge 9 commits intoapple:mainfrom
peterfriese:flatMapLatest/statemachine
Draft

feat: Add AsyncSequence.flatMapLatest operator#382
peterfriese wants to merge 9 commits intoapple:mainfrom
peterfriese:flatMapLatest/statemachine

Conversation

@peterfriese
Copy link

This PR introduces the flatMapLatest operator for AsyncSequence.

What's included:

  • flatMapLatest operator: A new operator that transforms elements of an asynchronous sequence into new asynchronous sequences, automatically cancelling previous inner sequences when a new element arrives from the outer sequence.
  • Implementation: Uses a state machine pattern to ensure thread-safe operation, including generation tracking, explicit cancellation, lock-based coordination, and continuation management.
  • Comprehensive tests: Extensive unit tests have been added to cover various scenarios, including error propagation, cancellation, and handling of empty sequences.
  • Evolution Proposal: A detailed evolution proposal (Evolution/00nn-flatMapLatest.md) outlines the motivation, detailed design, and comparison with similar operators in other reactive frameworks (ReactiveX switchMap, Combine
    switchToLatest).
  • Documentation Guide: A new documentation guide (Sources/AsyncAlgorithms/AsyncAlgorithms.docc/Guides/FlatMapLatest.md) provides an introduction, code samples, and practical use cases (e.g., search-as-you-type, location-based queries).

Motivation:

The flatMapLatest operator addresses the common problem of managing asynchronous operations where only the result of the most recent operation is relevant. This prevents wasted resources from stale operations and ensures users always see up-to-date information, particularly in dynamic user interfaces.

This PR is an implementation of #381

This introduces a simplified version of the flatMapLatest operator for AsyncSequence, along with a basic unit test. Note that this implementation uses unstructured concurrency and may have race conditions regarding task cancellation.
- Replaces naive implementation with a thread-safe approach using ManagedCriticalState.
- Introduces generation tracking to prevent race conditions where cancelled inner sequences could yield stale values.
- Adds test_interleaving_race_condition to verify correctness under concurrent load.
- Ensures Swift 6 Sendable compliance.
- Replaces AsyncThrowingStream implementation with a custom AsyncSequence, Storage, and StateMachine.
- Implements explicit state management using Lock for thread safety.
- Handles concurrency between outer and inner sequences robustly.
- Ensures correct cancellation propagation and error handling.
- Verified with test_interleaving_race_condition.
- Moves AsyncFlatMapLatestSequence.swift to Sources/AsyncAlgorithms/FlatMapLatest/
- Extracts FlatMapLatestStateMachine and FlatMapLatestStorage into their own files.
- Aligns project structure with other complex operators like CombineLatest and Debounce.
- Added test_outer_throwing to verify outer sequence error propagation
- Added test_inner_throwing to verify inner sequence error propagation
- Added test_cancellation to verify proper cancellation handling
- Added test_empty_outer to verify empty outer sequence handling
- Added test_empty_inner to verify empty inner sequence handling
- Fixed test_simple_sequence to be more robust against timing issues
- Changed from synchronous map with throwIf to AsyncThrowingStream
- Added delay to ensure proper error propagation timing
- Fixes intermittent test failures
- Removed LLM-style thinking comments
- Kept only essential, professional explanations
- No functional changes, all tests pass
- Added FlatMapLatest.md documentation guide
- Authored by Peter Friese
- Includes introduction, code samples, and use cases
- Covers search-as-you-type, location-based data, and dynamic config examples
- Compares with similar operators in ReactiveX and Combine
- Created SAA-00nn proposal for flatMapLatest operator
- Includes motivation, detailed design, and examples
- Covers implementation strategy with state machine
- Compares with ReactiveX switchMap and Combine switchToLatest
Copy link
Member

@phausler phausler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are more detailed review notes that can be made but these are perhaps the most impactful for the pitch phase.

self.storage = FlatMapLatestStorage(base: base, transform: transform)
}

public func next() async throws -> Element? {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple of notes here that might inform the rest of the potential pitch:
the next method should likely be the typed throws variant (because as it currently stands this algorithm always throws, which is less than ideal if the base components never throw)
that would then make the overload for the old variant of next (the unaddorned non-typed throws version as you have written) would be rethrows not throws

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on using typed throws, thanks for the suggestion! I see you implemented this in PR #395, so I will not change it here for the time being.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so my pr was just to update things, feel free to merge my branch into yours and continue iterating. the major concerns here are more for the review with regards to the closure throwing or being async etc. I can help out with getting the implementation over the line.

}

enum Action {
case startInnerTask(Inner, generation: Int, previousTask: Task<Void, Never>?, previousContinuation: UnsafeContinuation<Void, Error>?)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to potentially have the flatMap and switchToLatest families eventually only be driven by one task, do you think that is something we could transition to from this implementation?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried following the implementation of the other algorithms.

Maybe this is something we can look into once the initial version has been merged?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes this could be an optimization later down the road.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants