You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
When using actions/setup-python@v6, sometimes the build output will include the warning "WARNING: Cache entry deserialization failed, entry ignored." Something then treats this as an error and stylizes it as "Error: WARNING: Cache entry deserialization failed, entry ignored." This results in a "red" annotation even though the build succeeded.
Action version:
6
Platform:
Ubuntu
macOS
Windows
I have only seen this on macos-26 (ARM). I'm running my builds on multiple Ubuntu versions, multiple Windows versions, and macos15-intel, macos-26, and macos-26-intel, but I have only ever seen this problem on macos-26. It's possible it could occur on other platforms as well, but it happens every run with macos-26.
Runner type:
Hosted
Self-hosted
Tools version:
This is occurring on Python 3.10. I am also testing on 3.12 and 3.14, both on macos-26, but this occurs only on Python 3.10. It's possible it could occur on other versions as well, but it happens every run with 3.10.
Repro steps:
Add this to your workflow using macos-26:
Expected behavior:
For the action, when used as documented with supported options values, to not cause output that GitHub Actions treats as an error unless something actually went wrong.
Actual behavior:
The action succeeds, but results in "error" output that causes red annotations on the builds.
Thank you for raising this issue. We have investigated on the same and wanted to let you know that the "Cache entry deserialization failed, entry ignored" warning originates from pip's vendored cachecontrol library. More can be find out about the upstream issue from here. When setup-python sets up versions Python 3.8, 3.9 or 3.10 on macOS arm64 runners or 3.11, 3.12, 3.13 or 3.14 on macOS intel runners, and these build artifacts are bundled with an older pip version (e.g., pip 21.1.1 for 3.8, pip 22.0.4 for 3.9). During the setup process, pip is upgraded to latest version. When the newly upgraded pip attempts to read HTTP cache entries that were just written by the older bundled pip, it cannot deserialise them due to a difference in serialization format, and emits this warning.
Thank you for raising this issue. We're pleased to inform you that this has been addressed and resolved in PR #1335. The fix ensures that stderr warning messages are now correctly classified as warnings rather than errors in annotations. As this issue has been resolved, We will be closing it. Please feel free to reopen if you encounter any further related concerns.
Activity
v-chiranjib-swain commentedon May 21, 2026
Hy @beamerblvd ,
Thank you for raising this. We will investigate it and get back to you as soon as we have some feedback.
jmarrec commentedon Jun 9, 2026
I get it with 3.12.2 on macos-15-intel and macos-14 too: https://github.com/jmarrec/EnergyPlus/actions/runs/27175100828
v-lmvysakh commentedon Jun 10, 2026
Hello @beamerblvd,
Thank you for raising this issue. We have investigated on the same and wanted to let you know that the "Cache entry deserialization failed, entry ignored" warning originates from pip's vendored cachecontrol library. More can be find out about the upstream issue from here. When setup-python sets up versions Python 3.8, 3.9 or 3.10 on macOS arm64 runners or 3.11, 3.12, 3.13 or 3.14 on macOS intel runners, and these build artifacts are bundled with an older pip version (e.g., pip 21.1.1 for 3.8, pip 22.0.4 for 3.9). During the setup process, pip is upgraded to latest version. When the newly upgraded pip attempts to read HTTP cache entries that were just written by the older bundled pip, it cannot deserialise them due to a difference in serialization format, and emits this warning.
v-lmvysakh commentedon Jul 14, 2026
Hello @beamerblvd,
Thank you for raising this issue. We're pleased to inform you that this has been addressed and resolved in PR #1335. The fix ensures that stderr warning messages are now correctly classified as warnings rather than errors in annotations. As this issue has been resolved, We will be closing it. Please feel free to reopen if you encounter any further related concerns.