What is the expectation for pants cache functionality with goals that fail? For example, I have a python monorepo that I lint with ruff and pylint using

pants lint ::

. If pylint succeeds on 10 files and fails on 5, this information gets cached. If no files are modified, future executions of

pants lint ::

will ignore those 10 successful files. However, I have noticed that those same 5 files are linted again, even with no code changes. Presumably with no changes, pants should also know that those files will fail once again. Is this behavior intentional? Is it desirable for pants to re-lint those files even though they are guaranteed (perhaps this is where my logic is faulty) to fail? This discussion around a year ago suggests this is the intended behavior, but I am having trouble understanding why: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1692236280350199

This behaviour is something that each process can control, as makes sense for that process: https://github.com/pantsbuild/pants/blob/cfb3cafcac2386c909bc4a3fee3997e1bd8b03d7/src/python/pants/engine/process.py#L33-L46 For most tools, I'm imagining avoid caching failures is handy for two reasons: • avoid getting stuck with a flaky failure and needing to clear the cache/force a rerun somehow • rerunning with

--keep-sandboxes=on_failure

or similar works automatically Maybe there's other thinking too.

That all makes sense, and I agree with the logic behind it. Thanks for the link and the response.