Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#557 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
50/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
ios, sqlite, swift
Domain
database, mobile

Research direction

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.

Written by the indexing model from the issue text.

Description

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
Dominant language
Swift
Stars
1.9k
Forks
149
Avg merge
2d 18h
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pointfreeco/sqlite-data

All issues in pointfreeco/sqlite-data

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.