Task locals in async read/write

[rcarver]

Hello! Wanted to start a discussion about the async forms of read and write. These functions take an @escaping closure, which causes problems with structured concurrency tooling, specifically TaskLocal

Would it be possible to change these functions to not take an @escaping closure?

Issues with Swift Testing

Below is an demo of two key problems:

1. TaskLocal variables lose their scoped value
2. When #expect fails, it causes an additional error reported by Testing

import GRDB
import Testing

@TaskLocal var count = 0

@Test func taskLocalInAsyncRead() async throws {
  let dbQueue = try DatabaseQueue()
  try await $count.withValue(99) {
    print("count inside task local: \(count)")  // count is 99
    try await dbQueue.read { db in
      print("count inside async read: \(count)")  // ❌ count is 0
    }
  }
}

@Test func taskLocalInAsyncReadExpect() async throws {
  let dbQueue = try DatabaseQueue()
  try await $count.withValue(99) {
    #expect(count == 99)
    try await dbQueue.read { db in
      #expect(count == 99)  // ❌ count is 0
      // Test «unknown» recorded an issue at tests.swift:17:13: Expectation failed: (TaskLocals.count → 0) == 99
      // XCTest/HarnessEventHandler.swift:182: Fatal error: Issue 'Expectation failed: (TaskLocals.count → 0) == 99' was recorded at tests.swift:17:13 without an associated test. This may be due to calling #expect() or Issue.record() from a detached Task or another unknown context.
    }
  }
}

---

Other known incompatibilities

It's not only a Testing problem though, the TaskLocal issue could easily cause unexpected behavior in many application contexts.

• swift-snapshot-testing uses TaskLocal for the test configuration, so fails in confusing ways when used to test queries in an async context.
• swift-structured-queries introduces a wonderful assertQuery helper which does just that. If the test case must be async, these tools fail to behave correctly
• Using TCA in general, DB activity is often performed in async effects. As TCA and surrounding tools heavily use TaskLocal unexpected behavior could easily occur.

Tagging @stephencelis @mbrandonw for any additional insights or gotchas they might be aware of.

Thanks for considering!

[groue]

Hello @rcarver,

Your issue is that you can't access task locals from within asynchronous database access methods. Thanks for the report! It would be nice to support this indeed.

These functions take an @escaping closure, which causes problems with structured concurrency tooling, specifically TaskLocal.

They take an @escaping closure, because GRDB schedules asynchronous database accesses with DispatchQueue.async. Some people could jump to wrong conclusions, but we're not such people: if you're interested in the reasons why GRDB uses DispatchQueue, check this thread.

This issue thus boils down to allowing closures run by DispatchQueue.async to access task locals.

A quick Google search does not yield any immediate solution. And it is not quite easy to understand how to do it, or even if it is possible, when I read the Task-locals in contexts where no Task is available specification.

---

Until more research is performed, could you please share more information about your specific use of task locals? Maybe we can find an acceptable workaround. This topic could interest other GRDB users as well.

[groue]

Thank you very much for your investigations!

[groue]

Meanwhile the support for accessing task locals from asynchronous database accesses was shipped in v7.6.0.

[rcarver]

@groue fully confirmed here, thank you!

[groue]

👍 A nice smooth story in all involved repos ;-)

[groue]

@rcarver I recommend that you upgrade to v7.6.1, which fixes a race condition that was introduced in v7.6.0.