wsl.exe --update can fails with 403 and is not retried

[ssbarnea]

I already have seen this happening multiple times over the last weeks in the last weeks and I think we should add some kind of retry mechanism for it:

  C:\Windows\system32\wsl.exe --set-default-version 2
  For information on key differences with WSL 2 please visit https://aka.ms/wsl2
  
  The operation completed successfully.
    
  C:\Windows\system32\wsl.exe --update
  Forbidden (403).
    
  ::endgroup::
  Error: The process 'C:\Windows\system32\wsl.exe' failed with exit code 4294967295

Apparently the 403 error is not really a permanent error and it should be recoverable with retries.

https://github.com/jdx/mise-action/actions/runs/12547219939/job/34984712978?pr=157

It should be noted that in my case I was using Ubuntu-22.04 distro, which is still listed as active. Not sure if others are less likely to cause this error.

[Vampire]

Nah, this has nothing to do with the distribution, it happens before the distribution comes into play at all.
It happens when updating WSL itself to v2.
Sometimes the MS download server for that update is a bit bitchy.
I see the same occasionally in the daily integration tests.
I just hoped that either it is a problem on the server that goes away or just because I use it too often in a row, so waited for you complaining. :-D
Maybe you should complain to Microsoft instead that they either do not refuse to deliver the update, or even better do that update in the GHA runner image already so that the update is not necessary / is a no-op, that would also safe quite a bit of time for doing that update.

Anyway, I'll add an up-to-5-times-retry to compensate the unreliability.
I have the retry mechanism in-place for other actions already anyway.

[Vampire]

Unfortunately it still happens even with trying up to 5 times:
https://github.com/Vampire/setup-wsl/actions/runs/12565962765/job/35030909782
https://github.com/Vampire/setup-wsl/actions/runs/12576276453/job/35052306428

I increased the times to 10 now with the fix for #65.
But I fear that once it gets 403 is stays on 403 and only rerunning the whole workflow on a different runner agent fixes it.

You probably indeed need to complain to Microsoft that the update answers with 403.
Or even better make them install the update in the image building already for the windows-2022 image.

[Vampire]

Even with 10 times it still fails occasionally.
I don't think there is much I can do except for hoping actions/runner-images#10563 gets done soon.