Regarding the possible effect of incorrect O/S information on validation and work availability...

In summary, bad O/S identification shouldn't affect validation, but will be annoying when looking at results on the web site (or via an API) and can be a real nuisance to the scheduler (as we may have been seeing recently...)

The work availability issue has already been discussed here, but it may be worth a [partial] refresher on how Homogeneous Redundancy (HR) influences task selection, using standard BOINC code as a reference point -- I can't remember when that was last discussed in detail...

If HR is used for a project (true for WCG in all cases), the scheduler checks for various platform matching functions using O/S and CPU information (the platform information in the scheduler request isn't always suitable for that as it simply specifies an executable file type but doesn't identify critical [Windows] O/S subset cases...) -- there is a core set of tests done against O/S information (mostly for Windows) and against CPU types (as per host_info held or supplied).

However, as far as I can tell it always uses the platform information (e.g. x86_64-pc-linux-gnu) for application selection. (And WCG don't seem to support Anonymous Platform, so that's one difficulty out of the way!) This should mean that anything for a given WU that manages to download o.k, run, and return with a success state should not cause major trouble for the validator (and should usually validate!)

In standard BOINC the validator wrapper (non-project-specific part) isn't interested in platform differences and I see no reason why WCG would have changed that. The wrapper doesn't care whether the project uses HR or not, and trusts the scheduler to have done the task allocation correctly at the time of the host's work request. It just passes validation-related information to the project-specific validator subroutine and deals with the success or failure return codes.

Cheers - Al.

I don't use the Windows BIONC client at the same time as the Ubuntu BIONC client.
edit: I have cloned the windows IP to WSL2.

Ubuntu BOINC client on WSL2

CPDN - sched_request_climateprediction.net.xml
<platform_name>x86_64-pc-linux-gnu</platform_name>
<alt_platform>
<name>i686-pc-linux-gnu</name>
</alt_platform>

<os_name>Linux Ubuntu</os_name>
<os_version>Ubuntu 24.04.3 LTS [6.6.87.2-microsoft-standard-WSL2|libc 2.39]</os_version>
<n_usable_coprocs>0</n_usable_coprocs>
<wsl_available>0</wsl_available>

WCG - sched_request_www.worldcommunitygrid.org
<platform_name>x86_64-pc-linux-gnu</platform_name>
<alt_platform>
<name>i686-pc-linux-gnu</name>
</alt_platform>

<os_name>Linux Ubuntu</os_name>
<os_version>Ubuntu 24.04.3 LTS [6.6.87.2-microsoft-standard-WSL2|libc 2.39]</os_version>
<n_usable_coprocs>0</n_usable_coprocs>
<wsl_available>0</wsl_available>

Windows BOINC client - with WSL2 on it.

CPDN - sched_request_climateprediction.net.xml
<platform_name>windows_x86_64</platform_name>
<alt_platform>
<name>windows_intelx86</name>
</alt_platform>

<os_name>Microsoft Windows 11</os_name>
<os_version>Core x64 Edition, (10.00.26100.00)</os_version>
<n_usable_coprocs>1</n_usable_coprocs>
<wsl>
</wsl>

WCG - sched_request_www.worldcommunitygrid.org.xml
<platform_name>windows_x86_64</platform_name>
<alt_platform>
<name>windows_intelx86</name>
</alt_platform>

<os_name>Microsoft Windows 11</os_name>
<os_version>Core x64 Edition, (10.00.26100.00)</os_version>
<n_usable_coprocs>1</n_usable_coprocs>
<wsl>
<distro>
<distro_name>Ubuntu</distro_name>
<os_name>Ubuntu</os_name>
<os_version>Ubuntu 24.04.3 LTS</os_version>
<wsl_version>2</wsl_version>
<is_default/>
<libc_version>2.39</libc_version>
</distro>
</wsl>

Whilst checking on the latest set of Error tasks (all download errors, as expected!) I noticed that I've had quite a few Server Aborted retries early this morning (all for missed deadline tasks that clocked in late).

On examination, I found that several of them had an initial pair reporting Alpine Linux v3.21 or Linux Docker Desktop but actually running the 64-bit Windows application! When one of them got detected as No Reply at the deadline I happened to collect a Linux retry (as indicated by the O/S-derived platforms of the initial wingmen) -- they all went to a system running a 64-task cache and a maximum of 8 tasks at once, so none of them had started when the original result got reported late...

As it seemed likely that my other systems might have got some similar retries I had a brief look at some of my returned retries on other systems and found one or two that will be informative at validation time

The first one I checked was MCM1_0242978_2585 (WU ID 781531938) -- both initial tasks went to Windows systems, but one reported it was Docker Desktop and the other that it was Alpine Linux (but ran the Windows application)!

The Docker Desktop failed (Not started by deadline, which WCG doesn't display as such), triggering the retry I received and processed with the 32-bit Linux application. As it is a retry, I suspect it might be several days before the validator has a go at it, but it'll be interesting to see whether it does validate. However, after a bit more digging I found another one that introduced another misidentification candidate, Fedora Linux 41 (Container Image)...

This was MCM1_0242951_6988 (WU ID 781267674) which had one initial task reporting as Alpine Linux and one as Fedora Linux (but both running the 64-bit Windows application). The Fedora one missed the deadline, so I got yet another 32-bit retry which returned 90 minutes before the original task eventually reported in), so there were two Windows tasks pretending to be Linux and my genuine Linux task. All three validated ...

It might be o.k. to miss out on Homogeneous Redundancy for MCM1 using the current CPU applications, but if the same happened to an ARP1 WU I don't think the outcome would be as favourable

By the way, can someone tell me if Alpine Linux is what is reported for the original [default?] WSL?

Cheers - Al.

Al,
When I was having this problem, my OS was sometimes reported as Alpine Linux, sometimes as Docker Desktop and sometimes as Ubuntu (which was the flavour of Linux I had installed under WSL).
Cheers,
Mark

It looks like I'm getting a bunch of WUs almost every day, but validation is still falling farther and farther behind. At a glance it looks like about 10-20% of my returned WUs are being validated every day, the rest going back to August 27 are still waiting.