Hi there,
I’m learning how to use the CF Workers and I’m trying to test a simple worker that uses the Cache API. If I understood correctly, the only way to test a worker with some sort of debug mode is to use the preview, either manually or via the Wrangler. However, the Cache API doesn’t seem to work in that environment, any cache.match() returns null. Is that a known issue? I looked into the documentation, I couldn’t find a definitive answer to that.
If the Cache API can’t be used in the preview system, is there a way to test it, without having to go by trial and error, publishing the worker on a DEV environment? I couldn’t find a way to perform any debug, outside the preview mode, which makes things tricky.
That makes things trickier, when one needs to test a worker that handles caching. It looks like the only option is to publish it to the DEV environment, but I couldn’t find a way to debug it there.
I find it hard enough not to have some sort of integrated debugging tool (a step-by-step debugging, like the one offered by the browser). Is there a way to simplify the testing of deployed workers?
There is wrangler tail which returns to your terminal all console messages by the worker.
Testing the Cache API should really be a matter of testing that you are saving the correct responses, as there are only two basic methods. Do report the feedback from the button in the UI though, they will listen.
The wrangler tail command seems useful indeed. I guess there isn’t a publish --watch command, right? It’s quite common to make quick changes during the testing, a watch system like the one offered by the preview command would be useful.
As for the cache, checking what’s being stored and fetched is precisely what I was trying to do. The purpose of my worker was to add dynamic caching of HTML content. CloudFlare’s cache everything mode would not be suitable, because the content to be cached would depend on data other than the URL alone. The logic itself would be simple. In pseudo-code:
cache_key = url + other_stuff
response = cache.get(cache_key)
if(!response) {
// Fetch the request from the server. In STANDARD mode, that should
// allow the content to be generated dynamically, taking into account the
// "other_stuff" above
response = fetch(request)
cache.put(response)
}
return response
However, it turned out to be complicated to test, because I didn’t have a way to inspect what the cache returned. For example, if the response was incorrect, I couldn’t check if the cache returned a match, but had stored the wrong content, or the cache key was wrong, thus the wrong content was loaded.
I like the idea of the Workers a lot, but the testing is really hard, in my opinion.
Why not return via headers the fact that there was or not a cache match and then another header with the cache key? Headers work great for those things.
It is very strange to me that up until now there is no solution to this. Deploying the worker code and checking logs via headers/etc. is not a way to test and debug.
