Matthias Endler

Yeah, good idea. I wonder about the implementation part. Maybe we should support caching by status code. So `--cache-status 429` or something. Initially I was a bit conservative with the...

Actually, reading this again, I think what you were asking for is slightly different: the cache should be stored even if we encounter 429 status codes. Is that correct? If...

Sorry, I think that's what I meant. So we don't cache the 429s; just the rest. This way on the next run when we load the cache again, we see...

Here's the way I see it right now: * `429` indicates that the error is on the client-side, namely lychee made too many requests. The mitigation is to wait a...

This is fixed in `master` now. So you can already use it with `lychee-action@master`. It will be released with `v2`, which I'm planning to ship in a few weeks after...

I reflected on this as I went through the open issues and decided to not go forward with it for the time being. The reason is that I would like...

The cache file is to avoid repeated checks. For example, if the cache is valid for 24h and you run lychee multiple times within that time it would not check...

Thank you all for the valuable input on this topic. After reviewing the discussion, it's clear that the core challenge here revolves around managing broken links in PRs and the...

Good point. Some people ended up not liking the idea of this composite action. (Can't remember who, right now.) I think the argument was that we would risk diverging from...

Guess we can close this, as I don't want to go forward with it. See my last comment. From what I can see, users use lychee-action in various ways and...