CDN Hashing is broken

Support
,
1

Hello Netlify,
I’m evaluating the netlify deploy strategy. So far, I like it compared to firebase, heroku etc.
I am however, having an ongoing issue that is pretty much a showstopper:
N.B. My site name for this post is:
https://66f575b44391c20f74a74d20--coruscating-fairy-5a0bab.netlify.app

The issue is to do with CDN file hashing. I have searched the forums and found a number of posts relating to problems with netlify’s CDN hashing, but none have a solution.

Here is a description:
Environment:
npm v10.2.4
netlify cli: netlify-cli/17.34.2 win32-x64 node-v20.11.1
react: 18.3.1

Symptoms:
Note: This is an intermittent problem,…sometimes it works (approx 50%), often it does not and exhibits the behaviour described below.

I first clean/remove my dist folder, then run an npm run build to get a fresh dist folder and test it locally (using http-server).
I then run netlify cli:
netlify deploy --site coruscating-fairy-5a0bab --dir dist
(I have also used --prod flag - it does not change this behaviour)

The netlify cli output is this:
Deploying to draft URL…

  • Uploading blobs to deploy store…
    ​
    Netlify Build
    ────────────────────────────────────────────────────────────────
    ​

Version
@netlify/build 29.53.0
​
Flags
deployId: 66f5777021528c1a0fe3087b
dir: dist
open: false
prod: false
prodIfUnlocked: false
site: coruscating-fairy-5a0bab
skipFunctionsCache: false
​
Current directory
====================
​
Config file
No config file was defined: using default values.
​
Context
√ Finished uploading blobs to deploy store
√ No cached functions were found
√ Finished hashing
√ CDN requesting 0 files
√ Finished uploading 0 assets
√ Deploy is live!

Build logs: Netlify
Function logs: Netlify
Website draft URL: https://66f5777021528c1a0fe3087b--coruscating-fairy-5a0bab.netlify.app

If everything looks good on your draft URL, deploy it to your main site URL with the --prod flag.
netlify deploy --prod

You will note this line:
√ CDN requesting 0 files

This is a fresh build and is not the same as what the netlify CDN already has.
I have also tried this with a really old build version (months old) – hugely different from the current deploy, and it gives the same:
√ CDN requesting 0 files
Clearly the hashing is not working as intended.

In another post it was mentioned that there is no way to disable CDN diffing/hashing.
Not having the ability to force a fresh build to the CDN prevents me (and all of your customers) from being able to get the correct version into your environment.
I understand this can place a burden on your CDN and you probably don’t want cli users embedding a --force flag into their build…but if the hashing isn’t working, the cli will be someone else’s, not netlify’s which seems a shame.

It would be great if you can fix this, either by fixing the CDN problem or adding a --force flag to the cli to tell the CDN to upload all files no matter what.

Otherwise we all have to go to firebase, which I don’t like as much as netlify.

You should have sufficient information above to investigate. I will monitor this post so if you have questions I will endeavour to answer them.

This post is of course to try and address a problem I am having…it is also to help Netlify improve its service. :slight_smile:

Thank you

2

Hi,
As an extension to this, I did a SHA256 hash on two separate builds of my main react assets/index.XXXXX.js files:

d2cb4dbf631d56eecb4ca51265c1cf7fe815c0be00cb236690718a8dc84c6575
2306d521a371f44d67b93af5afaaebaef5394f7cbe59a031247b6413f97743d7
Clearly these are not the same!
Thanks

3

Hi, @Peter5. There is nothing to fix because nothing is broken. You appear to be misunderstanding the reason that no new files were uploaded and I will do my best to clarify. The reason is this:

  • every file in the deploy has been uploaded as some point previously for this same site in a earlier deploy

That above does not mean it is unchanged from the current deploy. It means that some previous deploy of the site, any previous deploy of the site, already had this file in it so we already have this version of the file.

So, the deploy did change some of the files. It just changed them to a previous version of the file because you had already upload that version in the past.

Please note, we are using SHA-1 checksums and not SHA-256. For the deploy id mentioned, 66f5777021528c1a0fe3087b, the checksum for that file is:

51adb5c8500608dcd7cab9a04a0e68212667221b

You already uploaded the file in this earlier deploy:

https://app.netlify.com/sites/coruscating-fairy-5a0bab/deploys/66f571a28e8a4d1637a70642

If you download the file from that deploy and from the deploy below (which is the deploy you mentioned), you will see they are indeed identical files:

https://app.netlify.com/sites/coruscating-fairy-5a0bab/deploys/66f5777021528c1a0fe3087b

The first deploy is where the file was uploaded for the first time. The second deploy didn’t need to upload it again because the checksum was found in the database of files for this site. The API then used the existing previous upload saving everyone time and bandwidth.

Now, that file is not identical on all deploys but they are identical on the two deploys above. The deploy I linked to first did occur before the deploy you linked to. This proves that you really did already upload that file in a previous deploy. This is why the deploy API skipped it. I knew it had the file already so it reused the existing file.

I can repeat this process for every single file in the deploy 66f5777021528c1a0fe3087b. Every single file has already be uploaded previously for this site in an earlier deploy. This is not preventing files from changing between deploys. Some files do change but they are changing to an earlier version. The API is just not wasting bandwidth by uploading it again when we already have a copy from an earlier deploy.

Here is a list of all deploys and the SHA-1 for that file (if it exists) for each deploy;

deploy created at      , deploy id               , SHA-1 for index.*.js
2024-09-26 18:44:19 UTC, 66f5ab8392c9be2ef0090aba, bbd684f216c5a1482930775dd6c80248a9332043
2024-09-26 15:36:12 UTC, 66f57f6c7fcc6227babbe146, bbd684f216c5a1482930775dd6c80248a9332043
2024-09-26 15:20:51 UTC, 66f57bd3eaf81120f6a94ea4, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 15:19:00 UTC, 66f57b64ae70e72158b7869d, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 15:02:08 UTC, 66f5777021528c1a0fe3087b, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 14:54:44 UTC, 66f575b44391c20f74a74d20, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 14:53:15 UTC, 66f5755b1c7fa61903359e80,
2024-09-26 14:53:06 UTC, 66f57552a9fae71c0dfeb1a7, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 14:52:33 UTC, 66f575318e8a4d1995a708db,
2024-09-26 14:51:56 UTC, 66f5750cee64de18b5e39b41, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 14:45:57 UTC, 66f573a569d59319d62b9331, bb4db807dc49dc34275f231d35bbc2ea5ba0b040
2024-09-26 14:44:53 UTC, 66f573658e8a4d178da706b4, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 14:42:30 UTC, 66f572d6f940d616239b69d6, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 14:37:22 UTC, 66f571a28e8a4d1637a70642, 51adb5c8500608dcd7cab9a04a0e68212667221b
2024-09-26 14:26:24 UTC, 66f56f10b1154010c71cea1e, bfbedbd78c6de0e14709e1b9744d5c735678ecd5
2024-09-26 12:34:09 UTC, 66f554c136be3e1c3241d4fb, e8162f2d8fda12af0e7c864e4b8d1971c331343d
2024-09-26 12:14:36 UTC, 66f5502ca5cf6501117ac6de, 617037500d893c7bd7f5564db4228e5f1b9b37af
2024-09-26 10:11:53 UTC, 66f533692aa0b9bcfa8270b4, c2a3f0580956ce71c6db183f81001ef30610cb78
2024-09-24 16:53:31 UTC, 66f2ee8bf31c111818e4be60, 0a728acdb2f246ffc61a00feceaa5468d34b8b85
2024-09-24 16:48:50 UTC, 66f2ed7219e35f1aabb4d880, fec40e3501fd1cec9d96b1541a63ba5babcdb399
2024-09-24 16:40:25 UTC, 66f2eb7982d3f7183342cd58, 2fd8cf21f1bf5a44c55f2b18530b152c7fe54a32
2024-09-24 13:55:12 UTC, 66f2c4c0af18660d1a8f2617, 29c31f52547a94dd998cef9fe65a28f4788d8231
2024-09-24 13:43:17 UTC, 66f2c1f55a9dc81d83df1b27, 05e30c9869f075127bb6cbdd1438073c6eca151d
2024-09-24 13:20:26 UTC, 66f2bc9ad1808a087cdf9ee6, 86030043422b65f37a11bd1940f02745218c4228
2024-09-22 20:34:37 UTC, 66f07f5dbbdedf128f7ac16a, 422fa7eeac867c818c5bff62fd251d17dddf63c7
2024-09-22 16:10:27 UTC, 66f041737b8506d294f1b72a, 8c259109a7b8b38323863a56cc381a41c77b8cd8
2024-09-22 16:00:21 UTC, 66f03f15cfd22bd31eabd2b1, de8e1a363f7b16f84613d1bbea221511ea918604
2024-09-22 15:55:09 UTC, 66f03ddd60bee9d25f626f2e, de8e1a363f7b16f84613d1bbea221511ea918604
2024-09-22 15:50:49 UTC, 66f03cd9ef2bafc11823fa2f, de8e1a363f7b16f84613d1bbea221511ea918604
2024-09-22 15:43:25 UTC, 66f03b1d33a5bbcb613d384b, de8e1a363f7b16f84613d1bbea221511ea918604
2024-09-22 15:28:44 UTC, 66f037acbbdedfc8757ac226, 42dbe49cdd0f8827a08f67106f97d3c580dc3ca2
2024-09-22 15:20:26 UTC, 66f035ba7b8506c717f1b665, a36f651a7f3c3172d73ed61e9d4b2be0315d5c8d
2024-09-22 15:15:26 UTC, 66f0348e33a5bbc3943d37fe, 54e3f427a3e849e51a38c70a0be047113f3c5ad3
2024-09-22 13:34:15 UTC, 66f01cd7ef2baf9f3523fe27, bef86cbb5e1f641f2f97f0048e32f2179291ee50
2024-09-22 13:13:23 UTC, 66f017f360bee9abc6626e35, 5113fe293f6faf7f9f1237522456c7d18090aedc
2024-09-22 13:04:52 UTC, 66f015f4a568a7a294024913, 24b6b66b4a0d1b56d39b0bcb854c7e1eb6a5f9ad
2024-09-22 12:55:43 UTC, 66f013cf3e2f929b23948e11, 198554cb55131a9db59093f95e6b1587716ab2f3
2024-09-06 11:41:52 UTC, 66daea8090eba46f78bc67e4, 685b1ec5c911a0c9f1ae03dee80d873dccc8489a
2024-09-06 10:26:58 UTC, 66dad8f2aeaf6452270bace7, 8f058d2f431f4bedaa928f1e2c7a5d636fe0d768
2024-09-06 09:38:34 UTC, 66dacd9aaa07a944b46f10b0, 7f62dba532f07a87822d65e15632851c0b2795d7
2024-09-04 20:54:28 UTC, 66d8c904473d9a4342ddf36e, 21e38ef8256677cd954d12d12770a587de6ce6b2
2024-09-04 20:37:35 UTC, 66d8c50f98399047d9470ab8, 5759476aa9c995b09007db0d7bdcdfecc319b55f
2024-08-28 17:42:12 UTC, 66cf61745ca721b162cd6926, 6dcde8b83cab6c65e4a7ad13be934f0317282de7
2024-08-22 14:35:08 UTC, 66c74c9cd921d340027a7fbc, 4159c1b3ec7c8072ac25dc182852120b09af9695
2024-08-22 13:46:57 UTC, 66c74151d1cee327ec1534b9, 78f540abb51bd17401e0c86f80f590609694c7a3
2024-08-12 13:40:21 UTC, 66ba10c5a5564d93e6267a5d, 2c5a77ca27dcd0cfb88e42378e2d83eea18a0838
2024-08-10 10:52:50 UTC, 66b74682a80f80168d489fbf, 167feaa193f1e9bcfec3c3ef9b4bc70147b2dffa
2024-08-10 10:44:46 UTC, 66b7449ea67c7215a7e462bc, d054c75a3b3851f523ebf2629cea8ec103efddf0
2024-08-10 10:38:13 UTC, 66b7431579ffcb13d5ae6c13, 4ccc7629586b2aded267e84844ab6a6d1266984f
2024-07-30 09:25:42 UTC, 66a8b196379d1827bbceb8f9, dcb1f583ff91a8e8b4b9bda5248a65bba01a2082
2024-07-30 09:17:47 UTC, 66a8afbb1dc65f229d9e25bb, e527c82befbca917de1679cbf0547781d2a81150
2024-07-30 09:11:16 UTC, 66a8ae3499d8e91dba8b7e0d, caa2bad75714e6afd4d1de2f1e69f80b7ae8842d
2024-07-30 09:03:36 UTC, 66a8ac68b6498b1c2d08e74e, 9ad88edccf11d0f9fb88d22e3adf6baf32d611dc
2024-07-30 08:43:27 UTC, 66a8a7affdcd5413989bfd8c, 748e83e0e25bc4c057d9d563e21be18d2a5262d9
2024-07-16 09:29:54 UTC, 66963d92a7f8eb6b895bac9e, 2d8c193e11fbb45fad90b99d8b8e94773f9241a8

As you can see, many deploys have identical version of that file. There are nine deploys that have the checksum of 51adb5c8500608dcd7cab9a04a0e68212667221b.

If there are other questions about this, please let us know.

4

Hi Luke,
Thank you for your response. I understand your explanation, and it makes sense…however I perhaps didn’t explain the detail relating to your explanation, so let me clarify:

I understand the CDN has detected a file with the same hash.
The reason for this is because I uploaded it to a different site (I believe it is hilarious-hamster-e7ddea - but it could be a different test staging site). This in itself would be fine, however there is something in the CDN logic that sees there’s an identical file (read permissions ok), but it cannot access (write permissions not ok?) it (remember this file is in a different Netlify site), so it does not request it in the CLI request, but it doesn’t update it either.
i.e. Seems the CDN cache/hashing mechanism is able to detect (read), but unable to update (write) across different site deploys.
There may be an entry in an internal CDN log somewhere saying something along the lines of:
‘yes I can see there’s a hash match, but I failed to copy it over to the current site as I’m not allowed to do that’ . . . or something similar.
Hopefully the above explanation makes sense, but do let me know if you’d l like further clarification or you’d like me to run any tests etc.
Thanks
Peter

5

Hi, @Peter5. Please believe me when I tell you that your assumptions are false. Please stop trying to prove that you are correct and instead please try to understand what I am writing because what I wrote is both correct and true.

I’m going to highlight the false assumptions inline below:

I understand the CDN has detected a file with the same hash.

The CDN is not involved. Only the deploy API endpoint is involved. This statement above is simply wrong. The deploy API detected a file with the same hash in a previous deploy of this same site.

The reason for this is because I uploaded it to a different site (I believe it is hilarious-hamster-e7ddea - but it could be a different test staging site).

That is incorrect. It was uploaded to this same site, not a different site.

This in itself would be fine, however there is something in the CDN logic that sees there’s an identical file (read permissions ok), but it cannot access (write permissions not ok?) it (remember this file is in a different Netlify site), so it does not request it in the CLI request, but it doesn’t update it either.

This is both unproven and untrue. Again, the CDN has nothing to do with this and even when the files are not uploaded they do update. They do change to the checksum version the CLI sent to the deploy API using the copy from a previous deploy of this same site.

Imagine I make a new site with three files with three checksums below (and clearly all the checksum are not real or valid - they are simplified checksums for clarity only):

  • one.html with checksum 11111
  • two.html with checksum 22222
  • three.html with checksum 33334

The CLI will shown:

√ CDN requesting 3 files
√ Finished uploading 3 assets

Then I make a new deploy with new checksums:

  • one.html with checksum 44444
  • two.html with checksum 55555
  • three.html with checksum 66666

Again, the CLI will show:

√ CDN requesting 3 files
√ Finished uploading 3 assets

Now, lets say the file one.html is reverted like so:

  • one.html with checksum 11111
  • two.html with checksum 55555
  • three.html with checksum 66666

At this point the CLI will show:

√ CDN requesting 0 files
√ Finished uploading 0 assets

However, the file one.html is still changed from the checksum 44444 version back to the 11111 version. The fact that no files were uploaded does not mean no files changed. It only means that no new files were uploaded. I think this is where you assume Netlify is making a mistake but this is not reality. The files do change, they just do not get uploaded a second time.

If you download the deploy where it says “CDN requesting 0 files”, you will see that the checksum for one.html did change back to 11111. The CLI just did not upload it because the API already has a copy in the first deploy and the checksum is how that is determined. The deploy does change even when “CDN requesting 0 files” is written (unless you are actually deploying only the same files from your last deploy and then the two deploys will be identical because nothing changed between the two deploys).

If you want to prove you are correct, then prove that none of the files in deploy 66f5777021528c1a0fe3087b exists in any previous deploys of this site. I can prove they do exist in previous deploys as shown below in the CSV format output:

file path, SHA-1 checksum, first deploy of this site where is appears, the date that deploy was created
/spinner.gif, edb5fb1c0d84af5233041fbe52b797964e403076, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/phishing_1280.png, 5d192f0688481979aa67bfd5ccaf216650da9ca0, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/marker-shadow.png, 7b6a8df63930381e96604e705168d0527d6b82bc, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/marker-icon.png, 60a90bcbb2b42b7ddb4556db94eb7c1084b0e5da, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/marker-icon-2x.png, cf3a536596b1f58e0ac805404183c8e6d6bdacb5, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/layers.png, c9e7528e491a39232ba24a2706c6c739d6fb0f06, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/layers-2x.png, 152a162333e46d24f9d89f566312fc0c64011dee, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/index.html, dd38c28cf9ee0a950e370f21cee77e7f1364e121, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/hacker_1280.png, a18d50e8b4f85db6694f966d296a5794067fdf4e, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/getitongoogleplay.png, 56a252bd7b83560d2fb1c99fab21d21100751d42, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/downloadontheappstore.png, 922503a9fb4f5fe1c532968c2888a3a9fa52da02, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/crosshair-white.png, d06577c680c6779e4ecb8e83a80ba0b917b2317f, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/crosshair-grey.png, 05c0573120674b6aa9a465565da465ed810ce9aa, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/color_balls_1920.jpg, d32e18f89752c30cc3262d2f5b626854031309ed, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/branding.png, dc5a282091fb68247b6193829114453910c297a0, 66f013cf3e2f929b23948e11, 2024-09-22 12:55:43 UTC
/branding-socprime.png, 3764905c773b96275bba3c21f85c4272ab7a67e5, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/branding-socautomation.png, ddc04f7ae782656ab402ce95f5755e029ec2058f, 66f013cf3e2f929b23948e11, 2024-09-22 12:55:43 UTC
/branding-soca.png, ddc04f7ae782656ab402ce95f5755e029ec2058f, 66f013cf3e2f929b23948e11, 2024-09-22 12:55:43 UTC
/branding-jt.png, 833f202f46915eaf06041f21fd5b6650463fbd80, 66f013cf3e2f929b23948e11, 2024-09-22 12:55:43 UTC
/assets/x.b78c660b.js, 7ea771c8b248f20530f9b2dd1c230e293fbbd9ad, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/trash.42fccfe3.js, f90367e9c68ca952ba593c0fda6134b3d4aab505, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/spinner.89eed656.gif, edb5fb1c0d84af5233041fbe52b797964e403076, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/assets/quadtree.661b8644.js, 90c8fb79be6d7aa7f7608c71a8b83589a168f8c9, 66dacd9aaa07a944b46f10b0, 2024-09-06 09:38:34 UTC
/assets/plus.3a5ba7be.js, ce51a8ef10562d8732a21d3719b1c508f28605ac, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/index.e1fa6b4b.js, 51adb5c8500608dcd7cab9a04a0e68212667221b, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/index.394a7a61.css, 8a0200eef153e09f35802b0eb9ddf0dde36fed21, 66f533692aa0b9bcfa8270b4, 2024-09-26 10:11:53 UTC
/assets/hooks.fba3be11.js, 5b4447202fc8f4115022f13a73564410f58309c5, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/highcharts.97d0cc0d.js, 6f7af865842e4bf5ac54305506ab9bbfc097ccd2, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/highcharts-react.min.c2425c95.js, 9feda6dccc0c890e05cfc2ddcafa282e3febc1cc, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/favicon.f2836030.ico, 11b53a7f0a842f845d53304aae05b4827cce7c1e, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/assets/check2.0b6ce584.js, bdfe98398cc1527442b855c2368ac5191aad36e8, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/tilelayer.d94d6f55.js, a6f8087f4484354fff0cd9da43fabaece7750f01, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/reportmanagerstub.63c126c7.js, 6a096384d1cfc73dc169703891f55f78ecd55cd7, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/rbvmworkflowmanagerstub.254ec140.js, 1c76d2983badc26501ff5b8c6dee2648837fb5bd, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/rbvmstakeholdermanagerstub.1e6a71dc.js, f455dca0028a2b28ef7b3050082901cec84b4a6a, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/rbvmriskmapmanagerstub.2fac34ea.js, 793254899fd03dbc6ab3f884270076361b4b900a, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/rbvmdashboardstub.6dad74ef.js, 3067d9c7dbdd5a9dd5cd2810c33f846f62c7ec23, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/rbvmcaasmstub.1167704f.js, da74e87dafedab0eadc67773d60f1c00ccd800a1, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/datahelixcontrolstub.a5182115.js, f77b813d6a9463d8900edec10526958df8093000, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/datahelixanalysisstub.3e340093.js, 6fa09bdc4f8648ff5abbe57cf9bfa146546ee092, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/casemgtstub.eab18853.js, ee82b3c89b2fc14905f9c905e2fdcf4c4bde43af, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/adminsettingsstub.8ff585c4.js, 6a2e337fde2261df53d694ea607e7c80f6cab49a, 66f571a28e8a4d1637a70642, 2024-09-26 14:37:22 UTC
/assets/adminsettingsstub.4bb41442.css, d79c5260cc81fe380d7fcd7a7192c1e8835ad199, 66963d92a7f8eb6b895bac9e, 2024-07-16 09:29:54 UTC
/runtime.js, f6b175d14ae19f8ec889351d85aee87b63bcf517, 66f554c136be3e1c3241d4fb, 2024-09-26 12:34:09 UTC
/datahelixai-white.png, dc5a282091fb68247b6193829114453910c297a0, 66f013cf3e2f929b23948e11, 2024-09-22 12:55:43 UTC
/netlify.toml, c574d229b542e1ab5a54f7e13d7ef48ac76d16de, 66a8a7affdcd5413989bfd8c, 2024-07-30 08:43:27 UTC

As you can see, every single file exists in a previous deploy of this same site (not some other site). This proves that what I told you it true. If you can disprove this somehow, please show the proof here. If you have questions, I will be happy to answer.