Internal inconsistency error (didStartTask)

Using Swift
, ,
1

When running some async unit tests, we sometimes see some errors spit out that don't fail our build. Examples look like:

Internal inconsistency error (didStartTask): targetID (174) not found in _activeTargets.
Internal inconsistency error (didEndTask): '12' missing from _activeTasks.

I'm not sure if this is a Swift runtime error. The "internal inconsistency" seems to hint at a Swift-level bug rather than a mistake in my code, but I'm not certain and don't want to write it off too quickly. It started showing up when I added unit tests that spawn their own Tasks and then use waitForExpectations to wait for them to complete. Inside of a unit test, do we need to do anything special to manage Tasks that might still be running when the test fails? Do we need to make sure to cancel them all? Is it safe to cancel ones that completed successfully?

4 Likes
2

@cocoaphony have you found any workaround on this?

1 Like
3

Have the same issue, but during running app mode in debug on simulator.
Workaround for my case:
Clean project -> Build -> Run == ALL is OK but time to waste ;(

4

We encountered this issue despite not using Swift concurrency. We found that disabling test parallelization for the affected test targets resolved the issue.

5

I have the same error but it affects my main target and not my test target, so I would assume that it does not have anything to do with it. :confused:

6

I'm also seeing these errors with the main target, and the build is incorrectly marked as successful. I think these issues appeared after adding local SPM packages. I'm using Xcode 14.2.

3 Likes
7

This has also been my case -- I have a local Swift package inside an Xcode project and changes to its modules causes builds to be incorrectly marked as successful with Internal inconsistency error (didStartTask): targetID (...) not found in _activeTargets, making it seem like an incremental build occurred. In reality, the build that gets run is stale and the only fix I have found is to do a clean build.

2 Likes
8

One workaround that may be faster that a completely clean build, I have found, was to go to the command line and build your target there. This ought to unjam the didStartTask error. Once that build completes, I can go back to Xcode and keep working/building. I haven't tried this for all target types, though.