concurrency runtime error

[JaapWijnen]

I'm getting the following error when trying to use the .task modifier on a view within a WithViewStore
"ViewStore.send" was called on a non-main thread with: Toolbar.Action.onAppear …
The "Store" class is not thread-safe, and so all interactions with an instance of "Store" (including all of its scopes and derived view stores) must be done on the main thread.

I don't fully understand what I'm doing wrong since I've seen it used here: https://www.pointfree.co/collections/composable-architecture/async-composable-architecture/ep199-async-composable-architecture-effect-lifetimes

It looks somewhat like this in my view:

struct ToolbarItems: ToolbarContent { 
  let store: StoreOf<Feature>
    
  init(store: StoreOf<Feature>) {
    self.store = store
  }
  
  var body: some ToolbarContent {
    ToolbarItemGroup(placement: .primaryAction) {
      WithViewStore(store, observe: ViewState.init) { viewStore in 
        Menu {
          Button {
            viewStore.send(.buttonTapped)
          } label : {
            Text("buton text")
          }
        } label: {
          Text("menu")
        }
          .task { await viewStore.send(.onAppear).finish() }
        }
      }
    }
  }
}

[tgrapperon]

For quite intricate reasons, View (often) inherits a MainActor context that is inferred in .task modifiers, especially when directly used in .body. It seems it's not the case for ToolbarContent. You can probably work around by adding @MainActor at the beginning of your .task:

.task { @MainActor in await viewStore.send(.onAppear).finish() }

[tgrapperon]

I you want more informations about the issue. In View, we have:

@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)
@_typeEraser(AnyView) public protocol View {
  static func _makeView(view: SwiftUI._GraphValue<Self>, inputs: SwiftUI._ViewInputs) -> SwiftUI._ViewOutputs
  static func _makeViewList(view: SwiftUI._GraphValue<Self>, inputs: SwiftUI._ViewListInputs) -> SwiftUI._ViewListOutputs
  @available(iOS 14.0, macOS 11.0, tvOS 14.0, watchOS 7.0, *)
  static func _viewListCount(inputs: SwiftUI._ViewListCountInputs) -> Swift.Int?
  associatedtype Body : SwiftUI.View
  @SwiftUI.ViewBuilder @_Concurrency.MainActor(unsafe) var body: Self.Body { get }
}

You can notice the @_Concurrency.MainActor(unsafe) which makes View.body @MainActor no matter what. However, it you look at the interface for ToolbarcContent:

@available(iOS 14.0, macOS 11.0, tvOS 14.0, watchOS 7.0, *)
public protocol ToolbarContent {
  associatedtype Body : SwiftUI.ToolbarContent
  @SwiftUI.ToolbarContentBuilder var body: Self.Body { get }
  @available(iOS 16.0, macOS 13.0, tvOS 16.0, watchOS 9.0, *)
  static func _makeToolbar(content: SwiftUI._GraphValue<Self>, inputs: SwiftUI._ToolbarInputs) -> SwiftUI._ToolbarOutputs
  static func _makeContent(content: SwiftUI._GraphValue<Self>, inputs: SwiftUI._GraphInputs, resolved: inout SwiftUI._ToolbarItemList)
}

You see no requirement, and ToolbarContent.body as no intrinsic actor inference. But it gets more complex. Because of this global inference behavior, the presence of a stored ObservedObject or StateObject would make the whole type infer @MainActor (because of its MainActor annotated wrappedValue), including ToolbarContent.body:

@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)
@propertyWrapper @frozen public struct ObservedObject<ObjectType> : SwiftUI.DynamicProperty where ObjectType : Combine.ObservableObject {
  @dynamicMemberLookup @frozen public struct Wrapper {
    internal let root: ObjectType
    public subscript<Subject>(dynamicMember keyPath: Swift.ReferenceWritableKeyPath<ObjectType, Subject>) -> SwiftUI.Binding<Subject> {
      get
    }
  }
  @usableFromInline
  internal var _seed: Swift.Int = 0
  @_alwaysEmitIntoClient public init(initialValue: ObjectType) {
      self.init(wrappedValue: initialValue)
    }
  public init(wrappedValue: ObjectType)
  @_Concurrency.MainActor(unsafe) public var wrappedValue: ObjectType
  @_Concurrency.MainActor(unsafe) public var projectedValue: SwiftUI.ObservedObject<ObjectType>.Wrapper {
    get
  }
}

and same for @StateObject (but not @State!). You can check this post from @ole or this discussion for more details
This behavior can be particularly tricky when using unannotated async helpers functions in View. Fortunately, this doesn't happen frequently when using TCA.

We could probably improve the situation by making WithViewStore closure @MainActor. But I think it would currently be a breaking change, as WithViewStore was not always specialized to View where the MainActor context is assumed (it isn't right now, but all its non-deprecated interfaces are). This is maybe something that can be discussed for the v1.0.