Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Nov 27, 2025

  • Understand the issue: UI loads from browser cache after firmware update

  • Analyze current caching implementation in wled_server.cpp

  • Build and test current codebase to establish baseline

  • Add WEB_BUILD_TIME generation to cdata.js

  • Include WEB_BUILD_TIME in generated html_ui.h

  • Update ETag generation to use WEB_BUILD_TIME instead of VERSION

  • Change WEB_BUILD_TIME to UNIX timestamp integer for flash savings

  • Remove unnecessary must-revalidate change per reviewer feedback

  • Remove unnecessary _codeql* gitignore entry per reviewer feedback

  • Build and test changes (npm test passes - 16/16 tests)

  • Run hardware build to validate firmware compiles (esp32dev SUCCESS)

  • Fixes UI loads from browser cache even after an update #5119

Original prompt

This section details on the original issue you should resolve

<issue_title>UI loads from browser cache even after an update</issue_title>
<issue_description>### What happened?

When updating the firmware the browser can still show the previous version of the UI which can lead to errors or missing UI elements.

To Reproduce Bug

Load UI, update, reload without full refresh.

Expected Behavior

Ideally the cache would be cleared if there was a change but not otherwise.

Install Method

Self-Compiled

What version of WLED?

0.16

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct</issue_description>

<agent_instructions>check current web page and resource caching, come up with a plan that still allows browser to cache pages, js files, css files but either has a shorter expiry or forces a re-check for integrity on every page load</agent_instructions>

Comments on the Issue (you are @copilot in this section)


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 27, 2025

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


Comment @coderabbitai help to get the list of available commands and usage tips.

Copilot AI changed the title [WIP] Fix UI loading from browser cache after firmware update Add must-revalidate to Cache-Control header to fix stale UI after firmware updates Nov 27, 2025
Copilot AI requested a review from DedeHai November 27, 2025 11:57
@DedeHai
Copy link
Collaborator

DedeHai commented Nov 27, 2025

@copilot: since VERSION is static in wled.h but should actually be the build date: can this be updated at compile time in cdata.js?

Copy link
Contributor Author

Copilot AI commented Nov 27, 2025

@copilot: since VERSION is static in wled.h but should actually be the build date: can this be updated at compile time in cdata.js?

The VERSION is currently a manual release identifier in wled.h. Updating it dynamically in cdata.js would require the build script to modify wled.h or generate a separate header with a build timestamp. This could work but represents a larger architectural change to the build process.

An alternative approach: cdata.js could generate a html_version.h with a WEB_BUILD_TIME constant that's included in the ETag generation. This would decouple the web build timestamp from the firmware VERSION while keeping the existing versioning scheme intact.

Should I explore implementing this in a follow-up PR, or would you prefer a different approach?

@DedeHai
Copy link
Collaborator

DedeHai commented Nov 27, 2025

@copilot since html_ui.h is already being dynamically generated: add WEB_BUILD_TIME to that header and use WEB_BUILD_TIME instead of VERSION in the ETag mechanism.

@Aircoookie
Copy link
Member

VERSION is static in wled.h but should actually be the build date

No, it shouldn't. If I were to build WLED 0.12 today, it should still have the original version number from 2021. It is more of a "codebase recency date" than a build date. Also, multiple people building different branches/versions on the same day would have the same version, which is very bad.

use WEB_BUILD_TIME instead of VERSION in the ETag mechanism.

This is an awesome idea and I think it is fine to use that to automate the UI caching on new builds.

Copy link
Contributor Author

Copilot AI commented Nov 27, 2025

@copilot since html_ui.h is already being dynamically generated: add WEB_BUILD_TIME to that header and use WEB_BUILD_TIME instead of VERSION in the ETag mechanism.

Implemented in 54f650a. cdata.js now generates WEB_BUILD_TIME (format: yymmddb with 6 build slots per day) in html_ui.h, and the ETag generation uses it instead of VERSION.

Copilot AI changed the title Add must-revalidate to Cache-Control header to fix stale UI after firmware updates Add must-revalidate to Cache-Control header and use WEB_BUILD_TIME for ETag to fix stale UI after firmware updates Nov 27, 2025
@blazoncek
Copy link
Contributor

This is an awesome idea and I think it is fine to use that to automate the UI caching on new builds.

Available in my fork for quite some time now. Not using cdata.js but set_version.py

@Aircoookie
Copy link
Member

@copilot 4-hour Build slots make no sense. This does not have to use the same format as version. Please revise to using YYMMDD_hhmmss (UTC)

Copy link
Contributor Author

Copilot AI commented Nov 27, 2025

@copilot 4-hour Build slots make no sense. This does not have to use the same format as version. Please revise to using YYMMDD_hhmmss (UTC)

Updated in 0adfc17. WEB_BUILD_TIME now uses YYMMDD_hhmmss format in UTC (e.g., 251127_131000).

@DedeHai
Copy link
Collaborator

DedeHai commented Nov 27, 2025

@copilot since this is for browser validation only, it is not required ot be human readable. To save on flash, make the #define a integer timestamp in UNIX time, we do not care about the 2038 rollover for validation. Then just printf that integer in in the ETag mechanism

Copy link
Contributor Author

Copilot AI commented Nov 27, 2025

@copilot since this is for browser validation only, it is not required ot be human readable. To save on flash, make the #define a integer timestamp in UNIX time, we do not care about the 2038 rollover...

Updated in 714a7f8. WEB_BUILD_TIME is now a UNIX timestamp integer (e.g., 1764251316) and the ETag uses %u format specifier to print it.

@netmindz
Copy link
Member

@copilot Does our webserver actually implement status 304 or are we just created etags that are then not referenced?

Copy link
Contributor Author

Copilot AI commented Nov 27, 2025

@copilot Does our webserver actually implement status 304 or are we just created etags that are then not referenced?

Yes, the webserver implements 304. The handleIfNoneMatchCacheHeader() function (lines 91-105) checks the If-None-Match request header against the generated ETag. If they match, it returns a 304 response instead of the full content. This function is called in handleStaticContent() before serving any static file.

Copy link
Member

@willmmiles willmmiles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After cleanup, this should get squashed down to one commit to reduce the history spam.

@DedeHai
Copy link
Collaborator

DedeHai commented Nov 28, 2025

@copilot please fix the requested review changes.

Copy link
Contributor Author

Copilot AI commented Nov 28, 2025

@copilot please fix the requested review changes.

Fixed in db71cf3. Removed the must-revalidate addition and the _codeql* gitignore entry.

@DedeHai DedeHai marked this pull request as ready for review November 28, 2025 06:17
@willmmiles willmmiles merged commit 75a7ed1 into main Nov 28, 2025
51 checks passed
softhack007 pushed a commit to netmindz/WLED-MM that referenced this pull request Nov 28, 2025
Add WEB_BUILD_TIME to html_ui.h and use it for ETag generation

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: DedeHai <[email protected]>
Co-authored-by: Aircoookie <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

UI loads from browser cache even after an update

6 participants