Wired 404 error deploy after 22 jan 2021 persist

Before yesterday I posted a problem with deploy. Details can ve seen here
Unfortunately when activate autopublishing stop working again commits after day 22.
I went back to last commit of day 22 and stoped autopublishing.
After some tests it seems that error is not present in preview, but it appears when publishing the deploy.
I actually think is a bug in Netlifly backend.

Hey there,
This is the commit that resulted in 404s: clean up · SEscobedo/AstraSolaris@6a39b2d · GitHub

You can see the 404s here: Astra Solaris - Solar system model

Can you change your .gitignore back to what it was before that commit and see if that helps?

Hi Jen.
Gitingore and all branch was restored to commit 14c5d6a at 28 January. It still resulted in 404. (the deploy of the same commit at day 22 works fine).
The last commit in the master branch is 583b174, deployed yesterday. In Netlifly it works all right at the deploy preview. But resulted in 404 when published. Something is happening when publishing the deploy.

hey there @SEscobedo , are you still dealing with this or has there been any resolution?

Hi @perry, I still looking for a solution, Any new commit fails when published (even when the preview works fine). I have to maintain the published commit at January 20. Just tried today and the problem isn’t fixed.

can you please post a recent build log that is failing?

This is the log of the last deploy. I looks fine, when I open the preview all works fine too, but when I publish the deploy, it gives the 404 error that I described in the post.

3:49:39 PM: Build ready to start
3:49:41 PM: build-image version: d84c79427e8f83c1ba17bcdd7b3fe38059376b68
3:49:41 PM: build-image tag: v3.6.1
3:49:41 PM: buildbot version: 44655717ddf0e7bd7f856f5b1154254de54b1d80
3:49:42 PM: Fetching cached dependencies
3:49:42 PM: Starting to download cache of 397.7MB
3:49:49 PM: Finished downloading cache in 7.342213266s
3:49:49 PM: Starting to extract cache
3:49:53 PM: Finished extracting cache in 4.216337955s
3:49:53 PM: Finished fetching cache in 11.709534999s
3:49:53 PM: Starting to prepare the repo for build
3:49:54 PM: Preparing Git Reference refs/heads/master
3:49:57 PM: No build steps found, continuing to publishing
3:49:57 PM: Starting to deploy site from ‘/’
3:49:58 PM: Creating deploy tree
3:49:58 PM: Creating deploy upload records
3:49:58 PM: 1 new files to upload
3:49:58 PM: 0 new functions to upload
3:49:58 PM: Starting post processing
3:49:59 PM: Post processing - HTML
3:49:59 PM: Post processing - header rules
3:49:59 PM: Post processing - redirect rules
3:50:00 PM: Post processing done
3:50:00 PM: Site is live :sparkles:
3:50:25 PM: Finished processing build request in 44.023398886s

can you please post a screenshot of your build settings?

@perry Sure, here it is. However I do not see anything wrong in the settings.

can i ask why you have a package.json file and node_modules folders in your repo (these should never be committed anyway) but you aren’t actually building a site?

Generally speaking, if the site needs to be built, you’ll need dependencies that are listed in the package.json, but in your case you seem to only be wanting to deploy the html files committed to the repo?

I’m a little confused by your setup I am seeing here :thinking:

Hi @perry
Yes, you are right in that point. Actually node_modules folder is in .gitignore file en dev branch. I remember I had some troubles using three.js without commiting the libraries. It simply didn’t worked, so I had to commit node_modules directory so threejs would do its job on line. I will try to fix the setup in dev branch, and publish it as branch deploy. Let’s see if it works.

@perry I have restructured the setup, and added a build instruction in Netlify deploy settings.
It works now, thanks.

HI, @SEscobedo. Thanks for letting us know the issue is resolved.

You don’t have to tell us, but if you wanted to share your solution here it might help someone else searching this site in the future looking for solutions to a similar issue.

I restored the setup of my code adding a building package. Rollup.js generates the static files after building the application. I added also in the build command “npm run build” in Build settings at Netlify. After that all worked smoothly. I still not knowing why the other setup was failing after publishing, probably there is a bug in the platform. Anyways the problem is fixed up.

Hi, @SEscobedo. About this:

Do you believe there is a bug at Netlify or with the framework being used to build the site? I ask because if you believe the is a bug at Netlify we do want to identity it and get it fixed.

Hi @luke . I believe there is a bug in the platform, because there was a different behavior in preview than in published website. A bug in the code should’ve presented the problem in the preview too. (a file was accessible in the preview but after publishing it was not accessible).

OK. That assertion is not obvious to me (and I am happy to admit when Netlify has a problem). Could you create some reproduction steps (including source code and how you show the problem), which we can follow to trigger the behavior again? Without that we’ll be hard pressed to investigate more deeply.

Well, probably I’m wrong. However for me it is suspicious the difference in deploy published vs deploy preview. I’ll try to reproduce the problem in another repository. Let’s see if it appears again.

Hi, @SEscobedo. When there are differences between a local site and the deployed site at Netlify, there can be many reasons.

The most common root cause I see is that there is a difference in the two build processes in some way. There can be many explanations for this:

  • different node versions
  • locally installed dependencies which don’t exist in the repo itself (meaning not in package.json)

The solution for this is to identify the local build configuration and then configure Netlify to use the same dependencies (node versions, packages, etc.).

However, if you have configured both Netlify and your local builds identically and they are still resulting in two different versions of the site, then that is unusual and could be a bug. It is just that there is usually an explanation for differences. Bugs can occur but they are relatively rare compared to configuration errors.