Provider tests wait on PagedFlow's real-time retry backoff (~40 s per iOS run)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 68/100
Línea de trabajo
Start with PagedFlow.kt lines 35-36 for the retry constants and the delay(wait) call at line 63, then read PagedFlowTest, which already uses runTest. The slow collectors are in PlexMediaProviderTest.kt near line 562 and the Emby (~664) and Jellyfin (~668) test helpers, which use runBlocking { toList() }. Run iosSimulatorArm64Test first to get a baseline timing. Done means these tests run on virtual time, the total drops well below 40 s, and Plex's real-I/O cases still pass.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Provider tests pay the PagedFlow retry delay on the real clock: about 40 s per iOS provider test run.
android/mediaprovider/server/src/commonMain/.../PagedFlow.kt:35-36setsMAX_ATTEMPTS=3andBACKOFF_BASE_MS=1_000L, anddelay(wait)runs at:63.PlexMediaProviderTest.kt:562, and the matching helpers in the Emby (:664) and Jellyfin (:668) tests, collect the flow underrunBlocking { toList() }, so the delays happen in real time.- Measured on
iosSimulatorArm64Test: PlexMediaProviderTest takes 24.6 s over 38 tests, and Emby and Jellyfin take 7.8 s and 7.5 s. The slow cases are the 3-4.6 s failure-path tests.
Fix: collect under runTest so delay runs on virtual time (PagedFlowTest already does this), or inject the backoff. Check that Plex's real-I/O paths still work under runTest.
Found by the codehealth measured-report experiment.
- Lenguaje dominante
- Kotlin
- Estrellas
- 231
- Forks
- 28
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin 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 timusus/Shuttle2
-
bug design impact:U1 P3 reach:R2 size:S
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
enhancement impact:U1 later P3 reach:R2 size:S
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
impact:U1 owner reach:R1 size:S
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 3/5 Medio día Aptitud para principiantes 55/100
-
bug impact:U2 P3 reach:R2 size:M
Dificultad 4/5 3-5 días Aptitud para principiantes 22/100
Todos los issues de timusus/Shuttle2
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
openbase/planetsudo.engine#107 ·
Los mantenedores suelen responder en 1 día
-
native-cpu: -Wreturn-type in skainet_row_threads.c:150 (worker fn has no return)Posiblemente ocupada @Doomguy-BFG9000 la tomó hoy. Abiertogood first issue size:xs skill:native
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
SKaiNET-developers/SKaiNET#1358 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
IBRAHIMDANS/i18nSupportPlus#577 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
PostHog/posthog-kmp#100 ·
Los mantenedores suelen responder en 2 días
-
Toronto time zone missingAbiertofeature request needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
FossifyOrg/Clock#521 ·
Los mantenedores suelen responder en 1 día