Admin UI button + CLI command to purge build cache on server

[angiehjort]

I somehow managed to break the build on server, and now i'm stuck. Whatever i do the build results in missing dependencies like d3 and stdlib, both via github and via cli

however i was able to successfully deploy the app first try on a new workspace, no issues

i suspect it has something to do with a build cache on server
would be nice to be able to reset it both via Admin UI and as a CLI command: different CI apps have this kind of feature

using [email protected] (latest), browser cache disabled, and i tried to run npm run clean and redeploy

[mootari]

Please try viewing your app with your browser cache disabled. If that fixes it you will likely need to update to the latest version of framework.

[angiehjort]

Update: i did the short term fix, but it added more confusion!
sorry for taking so much of your time, but i think i was able to deliberately reproduce the issue on [email protected]

so i've bashed space in every one of my JS files in order to force them have a different hash suffix
i deployed via pushing to master on Github, so i have the logs in the admin page:

the app now works, but it consistently uses [email protected]/8e2caae3.js — not what i see locally!

however when i build locally i have a different hash! is this expected?

rm -rf node_modules
npm i
npm run clean
npm run build

and as you can see the versions of my submodules match like PropmptsPopup.9373c924.js
so if i deploy via github and then deploy via CLI tool i will break the build, right? because different d3 file

ima try this now:

and indeed, now the page is broken. every one of my JS files still refers to

import * as d3 from "../../_npm/[email protected]/8e2caae3.js"/* observablehq-file */;

because these files are not updated from the previous build, but now i have a different d3 7055d4c5.js. with local build i have:

import * as d3 from "../../_npm/[email protected]/7055d4c5.js";

note also the difference in the comment /* observablehq-file */

[mootari]

This is great feedback, thanks! I'll have to see if we can retrace the issue on our end.

I assume this is the repo? https://github.com/Gapminder/ai-worldview-benchmark

[angiehjort]

japp. i just made a branch here https://github.com/Gapminder/ai-worldview-benchmark/tree/discussion-1919

so that i can keep pushing to master and unblock myself, while you have the project in the exact state where this issue happened

[mootari]

Earlier today we noticed that Cloudflare would still serve old files because they got cached by path and updating to 13.1.2 did not produce new hashes for the affected module files. We purged the Cloudflare cache, and at least for apps running on 13.1.2 we hopefully saw the last of this problem.

However, purging the cache is a rather exceptional step, and if you ever run into this kind of problem again please treat it as a bug on our end and let us know!

[angiehjort]

Hej @mootari! i just checked back at this and unfortunately the issue still persists, sorry to bother again

steps to reproduce:
build the app locally. from logs i see

...
build /_npm/[email protected]/_esm.js → dist/_npm/[email protected]/a7907588.js
...
copy src/components/oneChartCanvas.js → dist/_import/components/oneChartCanvas.8a337b9a.js
...

and in my dist/_import/components/oneChartCanvas.8a337b9a.js the file starts with

import * as d3 from "../../_npm/[email protected]/a7907588.js";

✅ this works when deployed manually and all is good
(i unlink my Github before to dodge the error and only deployed manually since we last talked here)

now i tried to link github repo to observable and pressed ▶️ Deploy button on the website

...
11:22:15.504Z deploy - 12 / 34 uploading _import/components/oneChartCanvas.8a337b9a.js
...
11:22:15.648Z deploy - 32 / 34 uploading _npm/[email protected]/c40c0177.js 🌶
...

❌ disabled browser cache, refreshed, now the page crashes

i open the "response" to /ai-worldview-benchmark/_import/components/oneChartCanvas.8a337b9a.js in the network tab in devtools, the file still starts with the same line

import * as d3 from "../../_npm/[email protected]/a7907588.js";

but of course there is no /ai-worldview-benchmark/_npm/[email protected]/a7907588.js to be found because it was generated with a different hash

i understand my oneChartCanvas.8a337b9a.js file is not updated, because no changes were made to my source file.
but why would D3 get a different hash in a local build and in the manual online build?

if a part of infrastructure takes the responsibility to set the hashes of dependencies, would it not check that these dependencies are referenced correctly?