Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Quick repeated calls to `await @Fetch*.load(...).task` inside `.task` modifier can result in stale query results

Abierto
  • ¿Algo no está bien?
#557 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
50/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
ios, sqlite, swift
Área
database, mobile

Línea de trabajo

Start by running the attached SubscriptionTaskReloadRaceApp reproduction and inspect the calls to FetchSubscription.task inside the view's .task modifier. Exercise rapid A-to-D load changes with a replacement delay below 100ms, then trace cancellation versus the new load; done means the @Fetch* results consistently match the latest load call.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
Description

(originally reported in Slack #sqlite-data channel)

Quick repeating calls to load can occur naturally in situations like handling a deep link on application start: the application first loads the initial/default query, followed by a quick reload to process the deep link.

Investigation reveals that awaiting the FetchSubscription.task is what triggers this bug. There's a race between the cancellation of the task (which will occur when the await is situated inside a view's .task modifier) and the handling of the new load. If the cancel wins, it prevents the new load from succeeding, resulting in stale data.

See attached demo app for a controllable repro - SubscriptionTaskReloadRaceApp_1.12.0.zip. The app cycles between query states A -> B -> C -> D, which each have their respective expected results ([A,A..], [B, B, ..], etc.). The app will halt whenever displayed results do not match expected results based on the most recent load call. Lowering the "Replacement load delay" to below 100ms reliably triggers the mismatch/stale results state. repro video

Checklist
  • I wrote this in my own words, and aimed to be as succinct as possible, even if I used AI to help research its content.
  • I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
  • I have determined whether this bug is also reproducible in a vanilla GRDB project.
  • If possible, I've reproduced the issue using the main branch of this package.
  • This issue hasn't been addressed in an existing GitHub issue or discussion.
Expected behavior

Results provided by the @Fetch* wrapper always match with the latest load call.

Actual behavior

Results provided by the @Fetch* wrapper can get stuck on results corresponding to a previous load call instead of the latest.

Reproducing project

SubscriptionTaskReloadRaceApp_1.12.0.zip

SQLiteData version information

1.12.0

Sharing version information

2.10.1

GRDB version information

7.11.1

Destination operating system

iOS 27

Xcode version information

27.0

Swift Compiler version information
6.4
Lenguaje dominante
Swift
Estrellas
1.9k
Forks
154
Merge medio
2 d 18 h
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pointfreeco/sqlite-data

Todos los issues de pointfreeco/sqlite-data

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.