Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#557 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
50/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
ios, sqlite, swift
Ambito
database, mobile

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
Swift
Stelle
1.9k
Fork
154
Merge medio
2g 18h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pointfreeco/sqlite-data

Tutte le issue di pointfreeco/sqlite-data

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.