Content manifest caching #4435#4643
Conversation
|
Lightbeam link |
allister-beamable
left a comment
allister-beamable
left a comment
There was a problem hiding this comment.
Generally looks fine, and should be a net improvement (or at least break even) for most usage patterns. Two things:
- needs a changelog entry
- is there any "safety valve" for the (hopefully rare) case of a corrupted or partially-incomplete cached manifest? some client-side way to force it to retry?
commit 951e626 Author: Piotr Siuszko <siuszko@zoho.com> Date: Fri Jul 17 16:51:42 2026 +0200 Merge release/5.1.x back to main
Changelog was updated, about safety valve I do not see a easy way to add it now as part of this work. |
|
|
||
| - Fixed an issue where SmallerJson was not serializing/deserializing null fields to default values. | ||
|
|
||
| ## [7.2.1] - 2026-06-30 |
There was a problem hiding this comment.
Good call, updating the log to accurately reflect the release date! (and a good reminder to the whole team to update it when cutting releases -- I think this specific one is my fault 😇)
allister-beamable
left a comment
allister-beamable
left a comment
There was a problem hiding this comment.
Looking good with the CHANGELOG updates.
Having discussed & thought about the "safety valve" topic: hopefully the circumstances that could lead to an actually corrupted or incomplete cache are vanishingly rare, and if they do occur the solution would be to uninstall & reinstall or clear device cache. Honestly, any mechanism trying to forestall or react to corrupted/incomplete caches would be more complex and error prone than the simple "turn it off and on again" hammer of uninstall & reinstall.
|
Lightbeam link |
2 participants
Resolves #4435 .
In my test when I was using the content manifest with less than 100 entries the time to get the content manifest were similar. When I've increased the manifest size to have bigger size (~1600 entries) the difference start to grow, but it was not consistent. I would say that the biggest win would be for cases where there is a big content manifest that changes from time to time so the clients would need to download a lot of data less frequently. There could be cases where there is a small manifest that does change often, then it could be worse than current solution. Instead of current one request(get me the latest manifest) it will perform two (get me the latest manifest UID, then the manifest with that UID) which is why I've introduced option to opt out of it with define symbol
BEAMABLE_OPTOUT_MANIFEST_FILE_CACHING.