Comment by Mihai_LeanZero on "The Globe: Following Your Reasoning Into Other People's Repositories"

The cross-origin fetch part is what stands out most to me here -- the browser reads another repo's .keep-the-why, then fetches that repo's state.json directly, no server in between. GitHub Pages happens to serve everything with permissive CORS by default, which is probably why this works smoothly for the examples here, but the post calls out "GitHub Pages or another static host." For a host that doesn't set Access-Control-Allow-Origin -- a bare S3 bucket without CORS configured, a plain nginx box serving static files -- does the Globe just silently drop that wave, or is there a visible failure state distinguishing "nothing there" from "blocked by CORS"? That seems like exactly the kind of thing that would be invisible until someone hits it.

Good catch, and it's half covered. Not silent: since a recent release a repository that fails to load in a globe or registry wave is listed in the legend as "not loaded", with the reason on hover, and the rest of the wave loads. But the reason can't tell CORS from "host down" - browsers deliberately report both as the same network error to the page, so all you get today is "Failed to fetch", and the docs don't say the export host has to send Access-Control-Allow-Origin. Fair point that this is exactly what nobody notices until they hit it. I'll make the message name CORS as the likely cause, document the header for the common hosts, and have the registry check warn when an export is served without it - that one can see the headers, the browser can't.

Should be fixed with PR #585 and #586, released in dashboard 0.6.8. In the status bar at the bottom of the dashboard (https://keepthewhy.com/dashboard/live/) it says something like "10 states · 628.3 KB" - click on that. That's the "State Monitor": it lists every state the page loaded, and from now on also every one that failed, with the reason (e.g. "network error or blocked by CORS") and the address. A failed repository is also named in the globe's legend.

That's a fast turnaround - PR shipped within the hour of the question. Naming CORS explicitly next to "network error" in the State Monitor is the right fix, since a bare "failed to fetch" really could mean five different things and a reader has no way to tell host-down from CORS from the repo just not existing. Having the legend call out the specific failed repository too closes the exact gap I was poking at - that's the detail that would otherwise have cost someone a long debugging session assuming their own export was broken.

Thanks for the hint :)

Search Hashnode