3 ms·

I think the problem with the proposed solution (https://github.com/golang/go/issues/44577#issuecomment-857200479 https://github.com/golang/go/issues/44577#issue

I think the problem with the proposed solution (https://github.com/golang/go/issues/44577#issuecomment-857200479 https://github.com/golang/go/issues/44577#issuecomment-85720...) is that the refresh is used to keep the cache from getting too stale. Would it be reasonable for golang modules on sourcehub to be served from a stale cache? The problem is that the refresh does a full clone which is too heavyweight. The other user who accepted that proposed fix had a single module that had a single user, so they can tolerate some weird caching behavior for their toy project.

joshuamorton 4y ago
If I'm reading correctly, it would not be stale, but be directly proxied, which would mean that a popular module could result in a higher overall qps (but this is also true if people clone directly from sourcehut). On the other hand, Drew's suggestion would actually result in stale caches. There comes a point (and it isn't a particularly far-off point) where disabling this would result in significantly increased traffic to sourcehut. That's a problem, but it's a problem with sourcehut's scalability.
- 8organicbits 4y ago
  > This may impact the freshness of your domain's data which users receive from our servers, since we need to have some caching on our end to prevent too frequent fetches. They mention that requests still are served from the cache when refresh is disabled.