[MBL-19677][S/P/T] Structured Concurrency foundations #3852

petkybenedek · 2026-01-21T14:46:41Z

What's new

This PR introduces AsyncStore, which makes use of structured concurrency to interact with the API and Core Data.

refs: MBL-19677
builds: Student, Teacher, Parent
affects: Student, Teacher, Parent
release note: none

refs: MBL-19677 builds: Student, Teacher, Parent affects: Student, Teacher, Parent release note: none

claude

Review Summary

This PR introduces a new AsyncStore implementation that provides async/await alternatives to the existing reactive Store pattern. The changes align well with Swift's modern concurrency model and follow the project's MVVM architecture.

Issues Found

Critical Bug in NSPersistentContainerExtensions.swift:99-103 - The performWriteTask methods are using self.context instead of the computed context property, which defeats the purpose of having a dedicated write context. This could lead to threading issues.
Memory Leak Risk in AsyncStore.swift:139 - The streamEntitiesFromDatabase() method returns a non-terminating stream without built-in cancellation handling. While the warning comment is present, consider adding safeguards or helper methods.
Silent Error Handling in AsyncStore.swift:147 - The forceRefresh method silently ignores errors with try?. This should at least log errors for debugging purposes.
SwiftLint Violation in AsyncStore.swift:54 - Line length exceeds the project's limit and should be broken into multiple lines.

Positive Aspects

Clean async/await API: The new AsyncStore provides a modern, ergonomic interface that will improve code readability compared to Combine publishers.
Offline mode support: Proper integration with OfflineModeInteractor ensures consistent behavior across online/offline states.
Smart caching: The cache validation logic is well-implemented with hasCacheExpired checks before making API calls.
Consistent error handling: Most methods properly propagate errors through async throws, giving callers control over error handling.
Pagination support: The loadAllPages parameter provides flexibility for different data loading scenarios.
Good separation of concerns: Private helper methods like fetchEntitiesFromCache, fetchEntitiesFromAPI, and fetchEntitiesFromDatabase keep the code organized and testable.

Recommendations

Fix the critical bug: The performWriteTask implementation must use the write context, not the view context.
Add unit tests: Given the complexity of async streams and Core Data operations, comprehensive unit tests are essential. Follow the conventions in CLAUDE-unit-tests.md.
Consider adding cancellation helpers: For non-terminating streams, provide convenience methods that handle cancellation automatically (e.g., with timeouts or lifecycle-bound cancellation).
Add logging: At minimum, log errors in forceRefresh to aid debugging.
SwiftLint compliance: Ensure all code passes SwiftLint checks before merging.

Core/Core/Common/CommonModels/Store/AsyncStore.swift

claude · 2026-01-21T14:48:17Z

Core/Core/Common/Extensions/CoreData/NSPersistentContainerExtensions.swift


    @objc open func performWriteTask(_ block: @escaping (NSManagedObjectContext) -> Void) {
-        let context = writeContext ?? {
+        context.perform { block(self.context) }


Bug: This implementation is incorrect. The method is supposed to use a write context, but it's always using self.context instead of the actual context variable returned by the context computed property.

The block(self.context) should be block(context) where context is assigned from the context computed property.

claude · 2026-01-21T14:48:19Z

Core/Core/Common/Extensions/CoreData/NSPersistentContainerExtensions.swift

+    }
+
+    public func performWriteTask<T>(_ block: @escaping (NSManagedObjectContext) throws -> T) async rethrows -> T {
+        return try await context.perform { try block(self.context) }


Bug: Same issue here - this should use the write context from the context computed property, not self.context. The correct implementation should be:

let writeContext = context return try await writeContext.perform { try block(writeContext) }

inst-danger · 2026-01-21T14:51:31Z

	Warnings
⚠️	This pull request will not generate a release note.

Affected Apps: Student, Teacher, Parent

Builds: Student, Teacher, Parent

MBL-19677

Coverage	New %	Master %	Delta
Canvas iOS	91.4%	81.06%	10.33%

Generated by 🚫 dangerJS against d481da6

inst-danger · 2026-01-21T15:21:10Z

Builds

Commit: Correct tests (d481da6)
Build Number: 1260
Built At: Feb 05 15:50 CET (02/05 07:50 AM MST)

Student	Teacher	Parent

suhaibabsi-inst · 2026-01-29T16:17:42Z

Core/Core/Common/CommonModels/Store/AsyncStore.swift

+        let entities = try await getEntities(ignoreCache: ignoreCache, loadAllPages: loadAllPages)
+
+        if assertOnlyOneEntityFound, entities.count > 1 { throw AsyncStoreError.moreThanOneEntityFound(entities.count) }
+        guard let entity = entities.first else { throw AsyncStoreError.noEntityFound }


So, here we are treating the empty data (no entities) as failure. Wouldn't that confuse code at call sites? As that would often be treated as a separate case in terms of UI ?

The other option would be to return nil, which is equivalent of just calling first on getEntities. This function is specifically created for cases when we expect an entity.
You can catch the specific error if you want to handle that case specifically, or just use first.
But I'm open to discussion, but if we want to return an optional, we can get rid of this function and just use first.

suhaibabsi-inst

@petkybenedek Great Work! I liked how AsyncFetchedResults turned to be. Though I have a couple of comments to consider to fully utilize the syntactic beauty of async/await coding.

suhaibabsi-inst · 2026-01-29T18:31:26Z

Core/Core/Common/CommonModels/Store/AsyncFetchedResults.swift

+import Foundation
+import CoreData
+
+@preconcurrency


I was thinking if we can get rid of this @preconcurrency attribute be used with our newly introduced Async types. How about using it with @preconcurrency import CoreData as that was by Apple, and then move the fetch method to an extension of NSManagedObjectContext.

@preconcurrency import CoreData public final class AsyncFetchResults<ResultType: NSFetchRequestResult> { .... public func fetch() async throws -> [ResultType] { try await context.fetch(request) } } extension NSManagedObjectContext { public func fetch<R: NSFetchRequestResult>(_ request: NSFetchRequest<R>) async throws -> [R] { try await perform { return try self.fetch(request) } } }

This way we keep the new code committed to the async/await model, isolating any source of pre-concurrency as much as possible.

Good idea, thanks!

suhaibabsi-inst · 2026-01-29T18:39:52Z

Core/Core/Common/CommonModels/Store/AsyncStore.swift

+    ///       Defaults to **false**.
+    ///     - loadAllPages: Tells the request if it should load all the pages or just the first one. Defaults to **true**.
+    /// - Returns: An async sequence of list of entities.
+    public func streamEntities(ignoreCache: Bool = false, loadAllPages: Bool = true) async throws -> AsyncThrowingStream<[U.Model], Error> {


How about renaming it to be more indicative of watching store updates. Something like:
updatesStream(), or simply ``updates()`.

I would name it back to streamEntities() because IMHO updates() is more confusing, as I would kind of expect it to update something or how can it return "updates". Also considered streamUpdates() or streamEntityUpdates(), but still prefer the original naming.
"Stream" is also what is being actually returned.

Core/Core/Common/CommonModels/Store/AsyncStore.swift

suhaibabsi-inst · 2026-01-29T18:59:31Z

Core/Core/Common/CommonModels/Store/AsyncStore.swift

+        let scope = useCase.scope
+        let request = NSFetchRequest<U.Model>(entityName: String(describing: U.Model.self))
+        request.predicate = scope.predicate
+        request.sortDescriptors = scope.order


This can be refactored out to a computed property or set at the initializer:

private var request: NSFetchRequest<U.Model> { let scope = useCase.scope let request = NSFetchRequest<U.Model>(entityName: String(describing: U.Model.self)) request.predicate = scope.predicate request.sortDescriptors = scope.order return request }

Core/Core/Common/CommonModels/Store/AsyncStore.swift

suhaibabsi-inst · 2026-02-01T18:50:22Z

Core/Core/Common/CommonModels/Store/UseCase.swift

+        try Task.checkCancellation()
+
+        return try await withCheckedThrowingContinuation { continuation in
+            self.executeFetch(environment: environment) { result in


Perhaps for later occasion:
It would be great if we can have a full-fledged async version of executeFetch function.

Yeah, we could also propagate down task cancellation to URLSession and we could make use of actors regarding token refresh. I kept it simple for this PR, but certainly an improvement worth making in the future.

Co-authored-by: Suhaib Al-Absi <[email protected]>

suhaibabsi-inst

Code +1

vargaat

My concern is that CoreData thread safety is not ensured with the current solution.

Consider the screenshot below:

The course was fetched on the view context (see result of po). The view context is associated with the main thread.
When await finishes we are on a background thread, from where accessing a main thread bound managed object potentially crashes.

If you start running the AsyncStoreTests repeatedly then it will crash after a while. On the below crash we can see that we are asked to work on the main view context, yet the code is executing on a background thread, thus the crash.

petkybenedek · 2026-02-05T12:47:47Z

It seems to me that the problem occurs outside of AsyncStore's scope. Marking the AsyncStoreTests with @MainActor thus ensuring that the tests are running on the main thread solves the crash issues.

refs: builds: affects: release note: test plan:

vargaat · 2026-02-05T13:43:43Z

It seems to me that the problem occurs outside of AsyncStore's scope. Marking the AsyncStoreTests with @MainActor thus ensuring that the tests are running on the main thread solves the crash issues.

This annotation will solve this particular problem. But if we modify the test's context not to run on the viewcontext but on a background context we will face the same issue (test running on the main thread while the object is from a background one). If we keep fetching CoreData on the main thread in the app, that will mean that every method using these async fetches should be @mainactor annotated which could result in a cascading warning tsunami. Also, fetching on a background thread would still not be possible and that would be a goal of ours to lower the load on the main thread in the future.

petkybenedek · 2026-02-05T13:53:01Z

What would be the solution here? Mapping Core Data objects to structs perhaps?

renamed, rearranged methods updated forceRefresh() updated fetchEntitiesFromAPI() to just fetch to database and not return entities

rh12

Code + 1

Thanks for the cleanup on AsyncStore!

Create AsyncStore

f0c61ea

refs: MBL-19677 builds: Student, Teacher, Parent affects: Student, Teacher, Parent release note: none

claude bot reviewed Jan 21, 2026

View reviewed changes

petkybenedek changed the title ~~[MBL-19677] [S/P/T] Structured Concurrency foundations~~ [MBL-19677][S/P/T] Structured Concurrency foundations Jan 21, 2026

Correct renaming

a179ad8

petkybenedek self-assigned this Jan 22, 2026

petkybenedek added 4 commits January 26, 2026 14:22

Created unit tests for AsyncStore

1595afa

Remove newline

666c444

Create AsyncFecthedResults and add getFirstEntity

4abcbb4

Add equatable conformance

6d1c18a

petkybenedek marked this pull request as ready for review January 29, 2026 15:58

petkybenedek requested review from Ahmed-Naguib93, JacksonHowe, ktheory, rh12, suhaibabsi-inst, szabinst and vargaat as code owners January 29, 2026 15:58

petkybenedek removed request for Ahmed-Naguib93, JacksonHowe, ktheory and szabinst January 29, 2026 16:14

suhaibabsi-inst reviewed Jan 29, 2026

View reviewed changes

Refactor

2126f83

suhaibabsi-inst reviewed Feb 1, 2026

View reviewed changes

petkybenedek and others added 3 commits February 2, 2026 09:33

Remove if expression

7050c72

Co-authored-by: Suhaib Al-Absi <[email protected]>

Remove if expression

c2da741

Co-authored-by: Suhaib Al-Absi <[email protected]>

Resolve build errors

035d971

suhaibabsi-inst reviewed Feb 2, 2026

View reviewed changes

vargaat requested changes Feb 4, 2026

View reviewed changes

Correct indentation

18a0a74

Requested changes

b2a42b2

refs: builds: affects: release note: test plan:

petkybenedek added 2 commits February 5, 2026 14:59

Simplifying call chains

5dbb3ae

renamed, rearranged methods updated forceRefresh() updated fetchEntitiesFromAPI() to just fetch to database and not return entities

Correct tests

d481da6

rh12 reviewed Feb 5, 2026

View reviewed changes

rh12 marked this pull request as draft February 6, 2026 18:04

[MBL-19677][S/P/T] Structured Concurrency foundations #3852

Are you sure you want to change the base?

[MBL-19677][S/P/T] Structured Concurrency foundations #3852

Uh oh!

Conversation

petkybenedek commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What's new

Uh oh!

claude bot left a comment

Choose a reason for hiding this comment

Review Summary

Issues Found

Positive Aspects

Recommendations

Uh oh!

Uh oh!

Uh oh!

Uh oh!

claude bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

claude bot Jan 21, 2026

Choose a reason for hiding this comment

Uh oh!

inst-danger commented Jan 21, 2026 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Affected Apps: Student, Teacher, Parent

Builds: Student, Teacher, Parent

Uh oh!

inst-danger commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Builds

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

suhaibabsi-inst left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

suhaibabsi-inst left a comment

Choose a reason for hiding this comment

Uh oh!

vargaat left a comment

Choose a reason for hiding this comment

Uh oh!

petkybenedek commented Feb 5, 2026

Uh oh!

vargaat commented Feb 5, 2026

Uh oh!

petkybenedek commented Feb 5, 2026

Uh oh!

rh12 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

petkybenedek commented Jan 21, 2026 •

edited

Loading

inst-danger commented Jan 21, 2026 •

edited by atlassian bot

Loading

inst-danger commented Jan 21, 2026 •

edited

Loading