Description:
When a new node version is released, the list of versions at https://nodejs.org/dist/index.json is updated and the binaries are uploaded at https://nodejs.org/dist/v`VERSION` (e.g. https://nodejs.org/dist/v19.8.1/).

However, the website sits behind a Cloudflare cache and sometimes the data seems out of sync: the API responds saying there is a version, but the binaries are not available.

This then causes setup-node to fail.

Action version:
3.6.0

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
When using 'latest' or 'current' or 'node'.

Repro steps:

(depends on caching status of node site)

GitHub workflow:

name: Repro
on: push
jobs:
  repro:
    runs-on: ubuntu-latest
    steps:
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '19.8.1'

Expected behavior:
Not entirely sure here. I think one of:

1. Try to fallback to the next most recent version.
2. Throw a clear error explaining the likely problem.

1 feels slightly risky: just because something has failed doesn't mean we should use a different version than the user might be expecting. Then again, the next most recent version might not be too bad. We could also limit this to only be for the case that the latest is unavailable AND it was released in the last day (so we know we're just covering this edge case - and people can't be too upset with a 1 day old version).

I'm leaning away from 2, if this will happen for each node release. It's very much unideal to break everyone's builds testing against the current version when new node versions come out: it makes using setup-node like this near unusable for people who want solid CI. 2 might be reasonable if through working with the nodejs team we can ensure their caching configuration is such that this happens more rarely.

Actual behavior:
Throws an unclear error, especially because of #714