Conversation
|
Review requested:
|
|
Welcome to Node.js, and thank you for your first contribution! Before review, please take a moment to read:
Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #65973 +/- ##
==========================================
+ Coverage 90.16% 90.22% +0.05%
==========================================
Files 771 785 +14
Lines 265485 269356 +3871
Branches 50466 51519 +1053
==========================================
+ Hits 239381 243021 +3640
+ Misses 17043 16857 -186
- Partials 9061 9478 +417
🚀 New features to boost your workflow:
|
be26547 to
9f5f91f
Compare
|
The test I added called This adds a fix for that in |
getDOMStorageItems() falls back to reading the live Storage object when its cached map is empty. When getWebStorage() cannot produce one, the fallback was skipped and the command still answered with Success and an empty entries array, so a frontend could not tell an empty store from a store that cannot be read. getWebStorage() returns nothing whenever globalThis.localStorage is missing or is not an object, which is the case for any process started without --localstorage-file. Return a ServerError in that case, matching how the other failure paths in the same command report problems. Reading the storage key in that same configuration aborted the process: localstorage_file is an empty string, and std::filesystem::absolute() throws on it under libstdc++ while returning the current directory under libc++. Node builds without exceptions, so the throw terminated the process. Use the error_code overloads of absolute() and weakly_canonical() and report the failure through DispatchResponse. Fixes: nodejs#65895 Signed-off-by: Avocado <ujubongbong@gmail.com>
9f5f91f to
a1f59f6
Compare
getDOMStorageItems()falls back to reading the liveStorageobject when its cached map is empty. WhengetWebStorage()cannot produce one, the fallback was skipped and the command still answered withSuccessand an emptyentriesarray. A frontend could not tell an empty store from a store that cannot be read.getWebStorage()returns nothing wheneverglobalThis.localStorageis missing or is not an object, which is the case for any process started without--localstorage-file.This returns a
ServerErrorin that case, matching how the other failure paths in the same command report problems.Note that this changes what a frontend sees for a process started without
--localstorage-file, which is the common case.sessionStorageis unaffected: it is always backed by an in-memory store, so it stays readable and keeps answering with an empty list.Fixes: #65895