Thanks for opening this pull request!

• 🎉 We are excited about your hands-on contribution!

Codecov Report

Attention: 19 lines in your changes are missing coverage. Please review.

Comparison is base (3d4bb13) 90.37% compared to head (9ea59d4) 90.55%.

@@            Coverage Diff             @@
##             main     #448      +/-   ##
==========================================
+ Coverage   90.37%   90.55%   +0.18%     
==========================================
  Files         161      161              
  Lines       16267    16401     +134     
==========================================
+ Hits        14701    14852     +151     
+ Misses       1566     1549      -17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@lsmilek1 You asked for me to take a look; it seems that CI tests are failing.

@mtrezza I see in the log error that builds fail:

Error: Process completed with exit code 65.

As I am new to CI (talking to mechanical engineer here) I cannot find out what I missed just by adding that few lines. In desktop xcode the build succeed. Is there any "how to" I could study to find out what where it hangs? Not even ChatGPT made me expert on this. :-)

Looking for example on the xcode-build-watchos I cannot see anything I could work with.

After trying to understand this a third evening I am confident to say I will not be able to resolve this. I don't think I should change any CI workflow configuration and cannot read anything useful from the logs here. I rolled back to 4.14.0

@mtrezza , I figured out the failing tests. Thanks to AI to explain me how all this works. :-) Would you be able to merge the changes? Thank you!

I believe to merge this we'd have to find out why some CI jobs are failing first.

@mtrezza, I tried in my local xcode and the test are every time successful. I noticed that jobs that succeed here (example xcode-test-ios) have the problematic test that calls backgroundQueue also failing:

✗ testThreadSafeSaveAllAsync, Asynchronous wait failed: Exceeded timeout of 20 seconds, with unfulfilled expectations: "Save object1", "Save object2".
✗ testThreadSafeSaveAllAsync, Asynchronous wait failed: Exceeded timeout of 20 seconds, with unfulfilled expectations: "Save object1", "Save object2".
✗ testThreadSafeSaveAllAsync, Asynchronous wait failed: Exceeded timeout of 20 seconds, with unfulfilled expectations: "Save object1", "Save object2".
✗ testThreadSafeSaveAllAsync, Asynchronous wait failed: Exceeded timeout of 20 seconds, with unfulfilled expectations: "Save object1", "Save object2".
✓ testThreadSafeSaveAllAsync (1.747 seconds)

Just that in these case the workflow file specifies to re-try up to 10x, what is not the case for spm-test and `spm-test5_2". As I am not experienced in this field and @cbaker6 is probably not around anymore, I am not sure if adding re-try to those spm-test is just fine or I should rather make timeout on the test expectation something very long:

wait(for: [expectation1, expectation2], timeout: 20.0) --> wait(for: [expectation1, expectation2], timeout: 100.0)

Is it ok that I adjust workflow file to re-try?

The failing codeCoverage is probably also something I will not get succeeding, yet it is required to pass

So, apparently the timeout increase helped to solve the problem. Might it be that these job test do any concurrency / background test much slower for some reason?