@Bo98 just making sure I understand the intended behavior here -- is the idea here that we'll hit the in-memory cache first, and then fall back to the file cache if the former misses? In other words, we'll end up priming the memory cache with the contents of the file cache, if it has a hit?

It'll read from the file cache first. It took me a while to understand how this chaining works but basically each middleware is responsible for firing the next one and then it pops up from there.

File cache HIT

Logging middleware (always does next.run) -> File cache (no next.run on a hit) -> Logging post-response

File cache MISS/Memory cache HIT

Logging -> File cache -> Memory -> File cache post-response (will save to cache if policy allows) -> Logging post-response

(In practice, this scenario is for things the file cache rejected anyway)

Both cache MISS

Logging -> File Cache -> Memory -> Default (i.e. fetch remote) -> Memory post-response (save) -> File post-response (save) -> Logging post-response

I initially thought the order was important but it probably isn't so you can probably adjust the order around if you want. Ultimately speed isn't really what matters here - it's mainly so that we avoid make the same request twice in a single run regardless of what Cache-Control says but still respect it across different runs.

Thanks, that's helpful!

Ah I think I remember one thing about the order: for non-200 codes I found the default cache policy (i.e. the file cache) reported cache hits while still querying the remote: https://github.com/06chaynes/http-cache/blob/12dde469fa2519d0fbb13b826db0b9a6706aafd5/http-cache/src/lib.rs#L1709. It's technically correct but was confusing when trying to debug the API.

So behaviour wise in terms of # of API calls it won't (or shouldn't) make a difference, but changing the order might make the debug logging more confusing given a Hit can still do a remote call for the file cache. The logging always takes the bottom of the stack so any form of pass back to the memory cache will ignore what the file cache attempts to claim.

I haven't fully thought through this yet, but I think there might be an edge case here -- tags can point to other tags (not just commits), so to fully flatten a tag to its underlying commit we probably need to recurse here.

(OTOH, we have tests for ref-version-mismatch that test this exact situation and they're passing, so I guess this works as is? I'm tired.)

Oh, I'm realizing that test might have changed underneath us, and is no longer the repo's state. I'm going to contrive a test for this.

Yeah that test seem to be a regular annotated tag:

$ git show-ref -d v2.7.8
aa7c1c80a07a27a84c0aa76d0cef0aad3830e330 refs/tags/v2.7.8
9d47c6ad4b02e050fd481d890b2ea34778fd09d6 refs/tags/v2.7.8^{}

Which is still a tag pointing to tag as described so still a good/correct test to have (and is the scenario already covered here), but I guess you're talking about a theoretical tag to a tag to a tag.

If a third level is possible I'd be interested to see how git ls-remote behaves.

Yeah, I was thinking about the fully general case. But it looks like git ls-remove does handle this for us:

https://github.com/woodruffw-experiments/zizmor-recursive-tags

has:

v1.0 (annotated) -> v1 (annotated) -> v1.0.0 (annotated) -> 3fdd4fc

which shows up in ls-remote as:

From [email protected]:woodruffw-experiments/zizmor-recursive-tags.git
3fdd4fca8fc76b254cefefca92381c41b28d1f0d        HEAD
3fdd4fca8fc76b254cefefca92381c41b28d1f0d        refs/heads/main
1accca34bff60347d96faaf713d328ca1250d37b        refs/tags/v1
3fdd4fca8fc76b254cefefca92381c41b28d1f0d        refs/tags/v1^{}
bcb36f3d551340e11b88c376e74e8ae77fc6cf0b        refs/tags/v1.0
3fdd4fca8fc76b254cefefca92381c41b28d1f0d        refs/tags/v1.0^{}
06f9d47abf340b709b412900a7b3ce33557d32b5        refs/tags/v1.0.0
3fdd4fca8fc76b254cefefca92381c41b28d1f0d        refs/tags/v1.0.0^{}

So the ^{} entry does always fully dereference the commit object, which is nice!