Windows R builds fail to solve environments (ERROR: Failed to get install actions, max retries exceeded.)

[mfansler]

Bug:

Windows builds for R are failing with messages like:

WARNING: failed to get install actions, retrying.  exception was: Unsatisfiable dependencies for platform win-64: {MatchSpec("msys2-conda-epoch==20160418"), MatchSpec("m2w64-fftw==3.3.4=6"), MatchSpec("m2w64-bwidget==1.9.10=2"), MatchSpec("m2w64-bzip2==1.0.6=6"), MatchSpec("m2w64-expat==2.1.1=2")}
Encountered problems while solving:
  - package m2-conda-epoch-20230914-0_x86_64 has constraint msys2-conda-epoch <0.0a0 conflicting with msys2-conda-epoch-20160418-1
  - package m2w64-bwidget-1.9.10-2 requires msys2-conda-epoch 20160418, but none of the providers can be installed
  - package m2w64-bzip2-1.0.6-6 requires msys2-conda-epoch 20160418, but none of the providers can be installed
  - package m2w64-expat-2.1.1-2 requires msys2-conda-epoch 20160418, but none of the providers can be installed
  - package m2w64-fftw-3.3.4-6 requires msys2-conda-epoch 20160418, but none of the providers can be installed

Could not solve for environment specs
The following packages are incompatible
\u251c\u2500 m2-conda-epoch 20230914.* 0_x86_64 is installable and it requires
\u2502  \u2514\u2500 msys2-conda-epoch <0.0a0 , which can be installed;
\u251c\u2500 m2-gcc-libs 11.3.0.4.* hd8ed1ab_0 is installable and it requires
\u2502  \u2514\u2500 m2-conda-epoch 20230914 *_x86_64, which can be installed (as previously explained);
\u251c\u2500 m2-libbz2 1.0.8.4.* hd8ed1ab_0 is installable and it requires
\u2502  \u2514\u2500 m2-conda-epoch 20230914 *_x86_64, which can be installed (as previously explained);
\u251c\u2500 m2-msys2-runtime 3.4.9.1.* hd8ed1ab_0 is installable and it requires
\u2502  \u2514\u2500 m2-conda-epoch 20230914 *_x86_64, which can be installed (as previously explained);
\u251c\u2500 m2-zip 3.0.3.* hd8ed1ab_0 is installable and it requires
\u2502  \u2514\u2500 m2-conda-epoch 20230914 *_x86_64, which can be installed (as previously explained);
\u251c\u2500 m2w64-bwidget 1.9.10.* 2 is not installable because it requires
\u2502  \u2514\u2500 msys2-conda-epoch 20160418 , which conflicts with any installable versions previously reported;
\u251c\u2500 m2w64-bzip2 1.0.6.* 6 is not installable because it requires
\u2502  \u2514\u2500 msys2-conda-epoch 20160418 , which conflicts with any installable versions previously reported;
\u251c\u2500 m2w64-expat 2.1.1.* 2 is not installable because it requires
\u2502  \u2514\u2500 msys2-conda-epoch 20160418 , which conflicts with any installable versions previously reported;
\u251c\u2500 m2w64-fftw 3.3.4.* 6 is not installable because it requires
\u2502  \u2514\u2500 msys2-conda-epoch 20160418 , which conflicts with any installable versions previously reported;
\u2514\u2500 msys2-conda-epoch 20160418.* 1 is not installable because it conflicts with any installable versions previously reported.
Reloading output folder: ...working... done
Solving environment (_h_env): ...working... failed
Reloading output folder: ...working... done
Solving environment (_h_env): ...working... failed
Reloading output folder: ...working... done
Solving environment (_h_env): ...working... failed
ERROR: Failed to get install actions, max retries exceeded.

Example: #25307

[adamblake]

Another example here, if it helps: #25286

[mfansler]

@isuruf is this possibly a consequence of the newer MSYS2 package builds mentioned in the Core meeting?

[mfansler]

@isuruf do you have any insights into this? It is leading to widespread failures.

[mfansler]

⚠️ I do not recommend this! It will likely just give us technical debt to pay later. Rather, just let it fail. Noarch recipes do not require a passing Windows build (skipped or not) to be merged.

It appears one workaround is explicitly declaring the previous epoch (as done for r-predicts):

requirements:
   build:
     ## Edit: NOT RECOMMENDED
     - msys2-conda-epoch ==20160418  # [win]

[mfansler]

That main pattern I see here is that this specifically happens on noarch packages. If you have a package that isn't noarch, then maybe it should be - that fixed it in most cases.

Users encountering failures in Windows on noarch packages can simply ignore this and reviewers should accept.