Fragile window abandonment during concatMap operations; silent data loss
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 38/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- java
- Área
- backend-api-design
Línea de trabajo
Comienza ejecutando las dos reproducciones usando Flowable.window() con concatMapSingle() y concatMapMaybe(), comparando las variantes de blockingSubscribe(). Rastrea la interacción entre el abandono de ventanas y la suscripción downstream; se considera terminado cuando las ventanas no se descartan silenciosamente o el abandono produce el error documentado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Combining the Flowable.window() family of operators with any of the Flowable.concatMap*() operators appears to cause window abandonment bugs which are sensitive to how the outer Flowable is processed downstream. This despite the given concatMap lambdas returning an Rx Single/Maybe ready to be subscribed as soon as they are returned and which will signal the upstream window for subscription synchronously.
In the demonstrations below, I subscribe to identical .window().concatMap() constructions with very slightly different downstreams (.blockingSuscribe(System.out::println) vs. .doOnNext(System.out::println).blockingSubscribe()) and they emit drastically different results due to silent data-loss.
Example: Windowing a stream into lists, similar to the buffer() operator.
public static void main(String[] args) {
final var content = Flowable
.rangeLong(0, 100)
.window(10)
.concatMapSingle(Flowable::toList);
System.out.println("Example 1: Expected behavior for concetMapSingle(Flowable::toList)");
content
.doOnNext(System.out::println)
.blockingSubscribe();
System.out.println("Example 2: Window abandonment & data-loss");
content
.blockingSubscribe(System.out::println);
}
Output:
Example 1: Expected behavior for concetMapSingle(Flowable::toList)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
[20, 21, 22, 23, 24, 25, 26, 27, 28, 29]
[30, 31, 32, 33, 34, 35, 36, 37, 38, 39]
[40, 41, 42, 43, 44, 45, 46, 47, 48, 49]
[50, 51, 52, 53, 54, 55, 56, 57, 58, 59]
[60, 61, 62, 63, 64, 65, 66, 67, 68, 69]
[70, 71, 72, 73, 74, 75, 76, 77, 78, 79]
[80, 81, 82, 83, 84, 85, 86, 87, 88, 89]
[90, 91, 92, 93, 94, 95, 96, 97, 98, 99]
Example 2: Window abandonment & data-loss
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[10]
[20]
[30]
[40]
[50]
[60]
[70]
[80]
[90]
Example: Windowing a stream into a simple reduction operation.
public static void main(String[] args) {
final var windowSums = Flowable
.rangeLong(0, 100)
.window(10)
.concatMapMaybe(window -> window.reduce(Long::sum));
System.out.println("Example 3: Expected behavior for concetMapMaybe(window -> window.reduce(Long::sum))");
windowSums
.doOnNext(System.out::println)
.blockingSubscribe();
System.out.println("Example 4: Silent data loss");
windowSums
.blockingSubscribe(System.out::println);
}
Output:
Example 3: Expected behavior for concetMapMaybe(window -> window.reduce(Long::sum))
45
145
245
345
445
545
645
745
845
945
Example 4: Silent data loss
45
10
20
30
40
50
60
70
80
90
The flatMap*() family of operators seem less prone to this behavior but don't guarantee to retain the upstream ordering.
Ideally, I'd expect window() to be compatible with concatMap(). But if such is impossible, I'd expect the window-abandonment detection described in https://github.com/ReactiveX/RxJava/wiki/What%27s-different-in-3.0#window-abandonment-in-window to at least signal an error.
- Lenguaje dominante
- Java
- Estrellas
- 48.2k
- Forks
- 7.6k
- Merge medio
- 3 h 9 min
- PR fusionados (30 d)
- 25
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ReactiveX/RxJava
-
4.x AI Enhancement Streamable
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
ReactiveX/RxJava#8299 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
4.x: FlowableBufferTest > longTimeAction() FAILEDQuizá libre de nuevo @akarnokd la tomó hace 73 días y no hay ningún pull request abierto. Abierto4.x Test-Failures
ReactiveX/RxJava#8280 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
4.x Discussion
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
4.x PR welcome Test Test-Failures
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
ReactiveX/RxJava#8075 · 4 comentarios ·
Los mantenedores suelen responder en 1 día
-
4.x: Cache/Replay operators to be more GC friendlyQuizá libre de nuevo @DragonFSKY la tomó hace 87 días y no hay ningún pull request abierto. Abierto4.x Enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
ReactiveX/RxJava#7912 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de ReactiveX/RxJava
Issues similares
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ReChronoRain/HyperCeiler#1743 ·
Los mantenedores suelen responder en 6 días
-
Weaviate: bump test image to 1.39.13 (CVE-2026-111943) and identify solon-ai via integration headerAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
status: needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
JabRef/jabref#17546 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
hiero-ledger/hiero-sdk-java#3010 ·
Los mantenedores suelen responder en 1 día