I’m not sure exactly how I caused this, but I now get this error consistently. This is possibly the same issue as this one.
What happens is that boot.ts attempts to get /.config, but the server returns 401 Unauthorized; this causes boot.ts to give up altogether. I think what might have happened is that I tried v1 edge and rolled back to v1 regular. However:
Resetting the application completely doesn’t seem to help - e.g. in Chrome, going to “Application->Storage->Clear site data” - the issue still persists.
While I’m experiencing this on cloudflare, I have indeed followed these instructions before, and even adding /.config to the bypass doesn’t help.
Not that it matters - the “unauthorized access” messages are visible on the server log (“Unauthorized access, redirecting to auth page”).
Ok, I think the issue here is that the service worker always falls back to a cached config when it gets any error from the /.config endpoint. You’re using cloudflare zero or something? What do you see in your browser’s logs, anything interesting in the network tab for the /.config request?
As a hack work around, what should work is unregistering the service worker and deleting your indexeddb databases manually (in that order).
At this point, there are no service workers to unregister, nor any indexeddb databases here. This is despite any attempts to clear the cache. For whatever reason, the favicon does persist (also visible under Application/Manifest), as well as the “Start URL: /#boot” section.
I think I’m just looking for an “obliterate everything you know about this domain, let me truly start over” option and failing to find a real one.
This does appear to be the same issue as mine. I removed the service worker and deleted the indexeddb databases from a working browser, and now I’m getting the error. This has only cropped up in the last ~24 hours. As noted in the other thread, I’m also using cloudflare but only as a cache (not using tunnels).
In my browser log, I’m seeing the error: “Failed to fetch client config SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data”
If I try to navigate directly to https://[domain]/.client/client.js (the url in the error), it retrieves fine, in that I see a .js file in my browser.
This increasingly smells as though cloudflare is caching more aggressively than we’d like, and that clearing various browser caches has no effect. I’m not near my machine at the moment, but perhaps trying with another browser instance could confirm or deny this.
I’m going to turn off caching on the domain (which isn’t really relevant to this site anyway) and leave it on DNS only and see what happens. does things
No dice. I nuked everything I could think of in the browser, and I’m getting the error.
Looking back, it seems like we have two errors flying in formation: the .config error and the .client error. Sorry for any confusion in my previous. I am getting the same fetch configuration issue though.
Edit: I just spun up v2 separately (not sharing anything with the v1 container other than being on the same host). Same error. That might not be a surprise.
Edit 2: Rebooted, because why not? Launched Zen, and my testing v2 site popped up with the default text as if nothing was wrong. Hit CTRL-R and received the fetch configuration error. In the network tab, it’s showing a 404 for .config/client.js. With v1, it’s a 401 error for the same path. Same error regardless of whether cloudflare proxy is on or off.
I’ve seen CF do some serious caching, also for silverbullet.md where the only solution was to somehow wait for the cache to expire for things to refresh.
I’ve just pushed an attempt to fix this to both main and v2. Builds should be live on docker soon. Hopefully this addresses it. Two issues that were there:
The service worker would eat the auth error and simply use a cached config
The /.config fetch in boot would not use manual redirect mode, nor handle the unauthorized status code case. I’ve fixed that now.
/.config was not an authenticated endpoint until now
Indeed just waiting for the next day (I was busy with other things anyway) caused the issue to resolve itself without me changing anything. Indeed, the currently-deployed version of silverbullet doesn’t even request /.config!
I have explicitly disabled caching for my silverbullet-on-cloudflare instance now. Notably:
The default caching level appears to be “No query string” - that is, /bla.js will be cached, but /bla.js?anything will not.
So what probably happened is that I deployed a version that contains 1dc1103, then rolled back to a version that doesn’t. Cloudflare cached the javascript that requests /.config, but /.config itself was no longer being served, wouldn’t have been cached by Cloudflare anyway as it’s JSON, and even gets served with Cache-Control: no-cache by http_server.ts for good measure.
Interestingly the issue has returned for me, but this time it’s combined with some sort of behavior that appears to be nuking docker entirely, which is concerning. (The behavior is that any container on this machine becomes immediately nonresponsive and I cannot even ssh into the box.)
