CircleCI caching: allow ftime to be ceil(ftime_req) in Base.stale_cachefile

[nrontsis]

It appears that caching functionalities provided by CircleCi (a leading CI/CD provider) can truncate timestamps to full seconds, resulting in re-compilations as below:

┌ Debug: Rejecting stale cache file /root/.julia/compiled/v1.8/ComponentArrays/cYHSD_3rQji.ji (mtime 1.6673960929277816e9) because file /root/.julia/packages/ComponentArrays/YyD7i/src/ComponentArrays.jl (mtime 1.667396093e9) has changed
└ @ Base loading.jl:2152

This PR relaxes the is_stale check to be robust against truncating-to-seconds timestamp mutations.

I can provide a minimal CircleCI configuration file to reproduce if this is helpful.

[DilumAluthge]

😬

[DilumAluthge]

Truncating to microseconds was one thing, but truncating to whole seconds seems way too coarse, in my opinion.

[DilumAluthge]

I think it'd prefer it if we instead implemented #45541

In other words, we would first check mtimes, and if the mtime check failed, instead of immediately considering the cachefile stale, we would check the hashes of the source files.

[DilumAluthge]

See comments above.

[nrontsis]

Thanks for the review, I agree that this is hacky.

But I might argue that this is less coarse that existing logic:

• For the new check to be a false positive, the modification time of the source code file must have occurred exactly at a "full-second timestamp", and is thus of "probability zero" (more accurately zero ->precision_of_mtime_in_seconds).
• For the new check to report true, we must have ftime <= ftime_req. Thus, by definition, it excludes the common case of cache staling, which is for the source to been modified after it has been compiled. For the purposes of the is_stale check as a whole, the already existing check:

( ftime != floor(ftime_req) ) &&           # Issue #13606, PR #13613: compensate for Docker images rounding mtimes

seems much more prone to produce a false positive.

[nrontsis]

Having said the above your suggested approach sounds much better.

do you have a rough idea of how much of a slowdown it can incur in practice?

[KristofferC]

I think this is fine since it is an exact check and not a range check like the microsecond check that was mentioned.

Dismissing as stale per the conversation above