Cache invalidation error

[HarmlessHarm]

Describe the bug
When a new update is rolled out, some of the cached js/css/html files aren't invalidated.
This causes a blank screen on initial page load which is resolved with a page reload.

I'm opening this issue to start to track and document some of the behaviour so we can look into it in the future

[HarmlessHarm]

This is the error message

[HarmlessHarm]

Enhancement Analysis

• Analyze issue details and attached error screenshot
• Research project documentation for context
• Structure enhanced specification
• Post final analysis

---

Bug Report Analysis

Questions for Reporter

Question	Answer
What hosting/deployment platform is used? Is there a caching layer or CDN in front of the SSR server?	Custom server, no CDN
Does the blank screen happen for all users after every deployment, or only intermittently / for some users?	Most deployments, expected to affect every user
What does the error in the screenshot say? (The image is not viewable externally -- could you paste the error text?)	(screenshot not transcribable)
Does the issue occur on first visit only, or can it also happen mid-session if a deployment goes out while a user has the app open?	First visit only
Are there any specific pages or routes where this is more likely to occur, or does it affect the entire app?	Entire app

Problem Summary

After a new deployment, users visiting the app see a blank screen because their browser still holds cached references to old JS, CSS, or HTML files that no longer exist on the server. The issue is resolved only when the user manually reloads the page.

User Impact

All users who visit the app shortly after a deployment may encounter a completely broken (blank) experience, with no indication of what went wrong or how to fix it -- users who do not think to reload the page will believe the app is down.

Expected Behavior

After a deployment, users should see the updated application without needing to manually reload. If stale assets are detected, the app should either transparently refresh or prompt the user to reload.

Actual Behavior

Users see a blank screen caused by the browser requesting cached asset filenames that no longer exist on the server. A manual page reload resolves the issue by fetching the new assets.

Next Steps

• Technical analysis to identify the caching and asset-hashing strategy in the build and deployment pipeline
• Implementation planning for a cache-busting or stale-asset recovery mechanism

---

Complete Context and Details (click to expand)

Reproduction Steps

1. Deploy a new version of the application to the production environment
2. Visit the app in a browser that previously had the old version cached (do not hard-reload)
3. Observe a blank screen instead of the expected application UI
4. Reload the page (Ctrl+R / Cmd+R) -- the app loads correctly with the new version

Additional Context

• App architecture: Vue 2 + Quasar 1 running in SSR mode, built with Webpack 4
• Hosting: Custom server, no CDN
• Frequency: Most deployments, expected to affect all users
• Trigger: First visit after deployment only (not mid-session)
• Scope: Entire app, all routes
• Error evidence: A screenshot was attached in a follow-up comment showing an error message (image not externally viewable -- error text not yet transcribed)
• Likely mechanism: The SSR-rendered HTML references hashed JS/CSS chunk filenames from the new build, but the browser cache serves stale versions of those files, or vice versa -- the old HTML references chunk filenames that no longer exist after deployment
• Workaround: Manual page reload resolves the issue every time
• Issue opened for tracking: The reporter noted this issue was opened to document and track the behavior for future investigation

[HarmlessHarm]

Complexity Assessment

Classification: COMPLEX

Metrics:

• Estimated files affected: 3-5 files
• Estimated lines of code: 150-300 lines
• Breaking changes: No
• Database migrations: No
• Cross-cutting changes: Yes (cache headers flow through SSR server → static file serving → build output)
• File architecture quality: Good (quasar.conf.js: 252 LOC, src-ssr/index.js: 112 LOC)
• Architectural signals triggered: External constraints (browser cache behavior), uncertain approach (multiple cache-busting strategies possible)
• Overall risk level: High

Reasoning: This issue involves cross-cutting concerns across the build pipeline (Webpack/Quasar) and SSR server cache-control headers. The problem stems from a mismatch between HTML asset references and cached JS/CSS files after deployments. Solutions require coordinating cache-busting logic across multiple layers: Quasar build configuration (manifest generation or hash versioning), SSR HTML cache headers, and static asset serving logic. The high impact (blank screens for all users post-deployment) combined with architectural decision-making required (which cache-busting strategy to implement) pushes this to COMPLEX classification.