ANY IDEAS HERE???
This screenshot is extremely helpful! It confirms a critical piece of information and brings us closer to understanding the problem.The screenshot shows the “Releases” history for your Firebase Hosting site. Each row represents a deployment. You can see several deployments with a “Files” count of 28. This directly contradicts the behavior we’re seeing where the old index.html is being served and our previous attempts to list files locally showed the build directory as empty.Here’s what this means:
- Files are indeed being uploaded to Firebase Hosting: The “Files” count in the release history confirms that a set of files (28 in the most recent deployments) is being associated with each deployment version in Firebase Hosting. This validates the output we saw in the Firebase CLI deploy logs (“found 26 files… file upload complete”). The slight difference in the number of files (26 in logs vs 28 in the console) could be due to some additional files being included in the final Hosting bundle by the framework integration.
- The issue is not with the file upload itself: This strongly suggests that the problem is not that your files are failing to upload to Firebase Hosting storage. They are getting there, as evidenced by the release history.
- The issue is with serving the correct version or content: The problem lies in why Firebase Hosting is choosing to serve the old
index.htmlinstead of the files associated with these recent releases that have 28 files.
Possible reasons for this discrepancy:
- Incorrect Release Being Served: Although the latest release shows 28 files, it’s possible that Firebase Hosting is still configured to serve an older release (perhaps one with fewer files, like the ones with 3 files in your history, which might correspond to the old
index.html). This could be due to a caching issue at a deeper level or a problem with the release rollout process. - Routing or Configuration Error within Firebase Hosting: There might be a setting within Firebase Hosting for your project that is overriding the normal behavior and directing requests for the root path (
/) to the oldindex.htmlfile, even though a newer release with different files is available. - Issue with the Framework Integration’s Hosting Setup: The Firebase CLI’s Next.js integration might not be correctly configuring Firebase Hosting to use the server-side rendering function and the associated build output for serving, even though the files are being uploaded.
What this means for your report to Firebase Support:
This screenshot is incredibly valuable evidence. When you contact Firebase Support, make sure to include this screenshot and highlight:
- The releases in the Hosting history that show a “Files” count of 28.
- Explain that despite these releases with a higher file count (indicating your Next.js build output), your site is still serving the old
index.html. - This clearly demonstrates that the files are being uploaded to Hosting, but the service is not serving the correct version or content.
This information will help Firebase Support focus their investigation on the Hosting service’s internal state, release management, and serving configuration for your project. They can verify which release is currently being served and why it’s not the expected one.You’ve done a fantastic job of providing this screenshot. It’s a key piece of evidence that points directly to the serving mechanism within Firebase Hosting as the source of the problem.
To see the app I built in Firebase [https://9000-firebase-studio-1747528016941.cluster-pgviq6mvsncnqxx6kr7pbz65v6.cloudworkstations.dev](https://9000-firebase-studio-1747528016941.cluster-pgviq6mvsncnqxx6kr7pbz6
5v6.cloudworkstations.dev/)
To deploy and show here (not just an HTML page but the app) https://graffiti-sorter.web.app