[question]: What happens with cachedSet::cached() when the resource becomes unavailable?

[gabyx]

I have a question regarding the

func (cs *cachedSet) cached() (Set, error) {
	if err := cs.r.Ready(context.Background()); err != nil {
		return nil, fmt.Errorf(`failed to fetch resource: %w`, err)
	}
	return cs.r.Resource(), nil
}

and the line in the example:
https://github.com/lestrrat-go/jwx/blob/develop/v3/examples/jwk_cached_set_example_test.go#L64

Question:

• When the resource(s) of cached underneath becomes unavailable, what happens to a call cached.Key(...). Will it block for ever? It seems so because the cached function above uses context.Background() on Ready()?
  Why does cached() not use a configurable timeout, such that it does not hang?

• How do you deal with unsuccessful requests to resources in the internal workers, when using this NewCachedSet?

Thanks a lot!

[lestrrat]

@gabyx IIRC, the only time a jwk.CachedSet can point to an invalid underlying httprc.ResourceBase is when the programmer explicitly asks the parent jwk.Cache to remove it via (jwk.Cache).Unregister. The parent jwk.Cache never purges old data, because it doesn't have a notion of TTLs.

So, assuming you made sure you got at least one instance of the jwk.Cache object for a given URL via (jwk.Cache).Ready(), and then create a jwk.CachedSet, your jwk.CachedSet will always be valid, albeit it's possible that the version you have in store could be old (if the underlying httprc mechanism fails to retrieve the remote resource). So if you are dealing with potentially flaky resources, you should go through (jwk.Cache).Ready() first, and then create a new jwk.CachedSet, which ensures that you have at least the most recent instance of the set in memory.

Does that make sense?

[gabyx]

iKind of makes sense :). Does the underlying http mechanism which retrieves the keys have a Timeout or will it block forever?

I thought that jwk.CachedSet can be seen as a set which behind the seen updates the keys by waiting for the resources the underlying worker goroutines updates.
But I couldnt figure out, what the worker goroutine do when the resource is not available (flakey connection), do they timeout and try again, or do they block? and what happens to the CachedSet I stored and I use: will (jwk.CachedSet).Key(...) also block?

[lestrrat]

@gabyx It depends on the HTTP client you specify for the resource. The moment I wrote this I realized I don't have an example in my examples/ dir. Having said that, the idea is that we do very little in terms of watching for timeouts, because the characteristics of each resource differs so significantly from case to case. The user needs to configure it via http.Client's Timeout

what the worker goroutine do when the resource is not available (flakey connection), do they timeout and try again, or do they block? and what happens to the CachedSet I stored and I use: will (jwk.CachedSet).Key(...) also block?

No, the worker's responsibility is to replace the old content once it fetches a new one. Until the worker goroutine is ready to replace the old content, your previous version will be available to you lock-free

[gabyx]

thanks for the explanations: I see, I guess I was confused about the cs.r.Ready(context.Background()) because it takes context.Background() and I thought is this gonna block since this is hardcoded. But thats not how it works apparently. So ready only communicates with the backend.

[lestrrat]

The .Ready bit should be the only synchronous bit. That API is necessary for the caller to make sure that a given URL is present in the cache at least once :)