`fail-on-cache-miss` for restore action not failing the workflow about cache

[NickLaMuro]

@dovisutu I believe you are on the right track, as we were running into this issue at my work place as well.

This PR added the earlyExit condition:

#1217

however, it wasn't implemented beyond just adding a default of undefined (which will always evaluate to false for that if). I assume what should have been done instead is the default should be based off that setting, and not just set to undefined.

cc @chkimes @kgrzebien @cwille97 as you were active on that PR.

---

For now, it seems like this was only merged into the most recent release (v3.3.2) to address this issue:

#810

So you can downgrade/pin your action/cache to v3.3.1 and you should be able to get this functionality back.

[eXigentCoder]

Can confirm, setting the version to v3.3.1 forced the workflow to fail correctly

My interpretation of the fail-on-cache-miss feature on the actions/cache and actions/cache/restore actions is that the workflow should stop and be considered a fail if there is no cache found with the given key.

I'm seeing evidence in workflows where using the actions/cache/restore action will not fail even if this option is set to true.

Snippet from the workflow file:

  Acceptance-Linux:
    name: "Acceptance tests (Linux)"
    needs: [Build-Snapshot-Artifacts]
    runs-on: ubuntu-20.04
    steps:
      - uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608 #v4.1.0

      - name: Bootstrap environment
        uses: ./.github/actions/bootstrap

      - name: Download snapshot build
        uses: actions/cache/restore@704facf57e6136b1bc63b828d79edcd491f0ee84 #v3.3.2
        with:
          path: snapshot
          fail-on-cache-miss: true
          key: snapshot-build-${{ github.run_id }}

      - name: Run comparison tests (Linux)
        run: make compare-linux

Evidence that the workflow continues past the failed cache restore (failing on the subsequent step, which it should have never reached.

[wagoodman]

erg, thanks @Rolexminus1 ? (you might have intended to write something different than echoing my description... or you're a bot, in which case... beep beep, boop )

For what it's worth, I think I found the problem that was causing the cache miss, which I'm also a little confused at:

      - name: Upload snapshot artifacts
        uses: actions/cache/save@704facf57e6136b1bc63b828d79edcd491f0ee84 #v3.3.2
        with:
          path: |
            snapshot
            .task
          key: snapshot-build-${{ github.run_id }}

followed by:

      - name: Download snapshot build
        id: snapshot-cache
        uses: actions/cache/restore@704facf57e6136b1bc63b828d79edcd491f0ee84 #v3.3.2
        with:
          path: snapshot
          fail-on-cache-miss: true
          key: snapshot-build-${{ github.run_id }}

Note the difference in the path provided (snapshot vs [snapshot, .task] logically).

My understanding is that I'd be able to store multiple paths and restore one of those paths, which does not appear to be working. However, in my case, this was a bug and I should have been restoring both paths anyway.

All that being said, it still doesn't address the original problem (fail-on-cache-miss doesn't fail the workflow) so I have the following workaround for now as a subsequent step:

      - name: (cache-miss) Snapshot build missing
        if: steps.snapshot-cache.outputs.cache-hit != 'true'
        run: echo "unable to download snapshots from previous job" && false

[vchernin]

I am seeing the same behaviour, using the same path in save and restore in my cache. Also on actions/cache/restore@704facf57e6136b1bc63b828d79edcd491f0ee84 # v3.3.2

Doing some investigating:

The thrown error is already being catched here:

cache/src/restoreImpl.ts

Lines 84 to 86 in 704facf

	} catch (error: unknown) {
	core.setFailed((error as Error).message);
	}

But it will only exit with an error if the calling function catches an error. (earlyExit seems to always be set to true).

cache/src/restoreImpl.ts

Lines 93 to 100 in 704facf

	try {
	await restoreImpl(stateProvider);
	} catch (err) {
	console.error(err);
	if (earlyExit) {
	process.exit(1);
	}
	}

The try catch of the callee function probably just needs to be removed for this to work. So core.setFailed((error as Error).message) should be moved to the caller error handler.

[s0undt3ch]

This has worked in the past for us.

[dovisutu]

Also run into the said issue that fail-on-cache-miss not failing, although initially I suspected that it was me that was doing things wrong...

I wonder, though, if cache and restore use pretty much the same (not exactly) logic on catching [if I could read Typescript correctly], why should cache work fine on fali-on-cache-miss? Or is it also failing, yet neglected for its (maybe?) rare usage?

if (earlyExit) { 
    process.exit(1); 
}

If I understood correctly, shouldn't exiting with return value of 1 already fail a step, then?