Deploy summary says "1 new file uploaded" but old subfolders (from a previous deploy) still appear in the current deploy's file browser

Support
1

Hi,

My site (remarkable-haupia-90770d, custom domain sharaku.net) is a Netlify Drop site (manual drag-and-drop deploys, no Git connection, no build step).

What I expected:
When I drag a folder to the deploy dropzone, the new deploy should fully reflect the exact contents of that folder.

What actually happened:

  1. I dragged a local folder that I had manually verified contains only 15 items (no subfolders other than icons/ and netlify/).
  2. The new deploy (“Today at 1:37 PM”) was created successfully and shows “Published”.
  3. Its “Deploy summary” says “1 new file uploaded / 1 asset changed”.
  4. However, the “Deploy file browser” for that exact same deploy still shows 71 total files, including two subfolders (sharaku-v13/ with 20 files, sharaku-v15/ with 21 files) that are not present in the local folder I dragged.
  5. These old files are genuinely live and publicly accessible, e.g. https://sharaku.net/sharaku-v13/buddha-dharma-login.html returns a real page (not a 404).
  6. I confirmed via Finder that the local folder I dragged does not contain sharaku-v13 or sharaku-v15 anywhere.

What I’ve already ruled out:

  • Browser cache / CDN in front of Netlify (not using Cloudflare or similar; confirmed via incognito window)
  • Re-checked the local folder contents multiple times before dragging
  • This is not a Git-connected site, so there’s no build cache involved

Question:
Why would a deploy summary showing “1 new file uploaded” still include 71 total files (including subfolders that don’t exist in the dragged folder) in that same deploy’s file browser? Is there a way to force a truly clean deploy that only contains exactly what was dragged, or a way to remove sharaku-v13 and sharaku-v15 from the live site directly?

Any help would be greatly appreciated. Thank you!

2

Update: I was able to isolate this to the browser drag-and-drop deploy path specifically.

I bypassed the dashboard’s drag-and-drop UI entirely and created a deploy directly via the API’s file digest method (POST /sites/{site_id}/deploys with a files digest computed locally, then uploading only the required files), using the exact same local folder (15 items, no sharaku-v13/sharaku-v15).

Result: the resulting deploy contained exactly the files I submitted (22-23, matching the local folder structure after expanding subfolders) — sharaku-v13 and sharaku-v15 were completely absent, confirmed via GET /deploys/{deploy_id}/files.

I then promoted that clean deploy to production via POST /sites/{site_id}/deploys/{deploy_id}/restore, and the live site (and the Deploy file browser for that deploy in the dashboard) now correctly shows 23 files with no trace of sharaku-v13/sharaku-v15. https://sharaku.net/sharaku-v13/buddha-dharma-login.html now returns a proper 404.

So it looks like the site-side deploy/file storage itself was fine — the bug was specific to how the dashboard’s drag-and-drop flow built (or reused) the file manifest it sent to the API. Wanted to share this in case it helps narrow down the root cause for others hitting the same issue, or in case someone from the Netlify team wants more detail on the working deploy ID (6a613878f8d6bb3fd3a99f29) for comparison against a broken drag-and-drop one.

For now I’m deploying via the API instead of drag-and-drop as a workaround, so this is resolved for us — just wanted to close the loop with what I found.

3

Important follow-up: The digest-deploy + /restore approach above successfully solved the stale-folder issue, but I discovered a serious side effect a few hours later — production Functions disappeared entirely (0 functions listed under Site → Functions, “No functions found in production”).

Looking at the deploy log for that digest-deploy, the Building and Deploying stages were both marked “Skipped” (only Post-processing ran). It seems the digest-deploy API path doesn’t trigger the same build pipeline that a browser drag-and-drop deploy does, so anything under netlify/functions never gets bundled/registered as a Function, even though the files are physically present in the deploy’s file browser.

For anyone using this same digest-deploy workaround for a similar stale-file issue: please verify your Functions are actually listed under Site → Functions after promoting the deploy, not just that the file browser looks clean. I ended up rolling back to a normal drag-and-drop deploy to restore Functions, which reintroduced the original stale-folder issue — so I still don’t have a single deploy method that solves both problems at once. If anyone knows how to trigger a proper build (including Functions) via the API digest-deploy path, that would be extremely helpful.

4

Update — found the fix. The issue is that when you send a plain file digest to POST /sites/{site_id}/deploys, Netlify only treats it as static assets. Functions need to be declared and uploaded through a separate mechanism, documented here: Get started with the Netlify API | Netlify Docs

Specifically:

  1. Include a functions object (not just files) in the initial digest request, with each function name mapped to a SHA256 (not SHA1) of its zipped contents.
  2. The response’s required_functions array tells you which function zips actually need uploading.
  3. Upload each one individually to PUT /deploys/{deploy_id}/functions/{function_name}?runtime=js, with the function’s .js file zipped together with any local dependencies (in my case a shared utils/ folder that the function require()s).

Once I did this, the deploy summary correctly reported “N functions deployed,” and they showed up under Site → Functions after promoting with /restore. Combined with the earlier fix, this gives one deploy method that avoids both the stale-folder problem and the missing-Functions problem. Hope this saves someone else the same afternoon of confusion!