Fix ENOENT during symbolication for known source URLs #910
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
As reported in expo/expo#17903, Metro logs errors to console attempting to read nonsense file paths. This occurs when trying to build a code frame for a URL
frame.file
, which Metro should skip attempting for any URLs it has already seen. Typically, URLs reach this point when a particular frame cannot be symbolicated.The problem goes back to 8cf2434, which introduced resolving the "file" to an absolute path before checking for its presence in the list of known URLs. The
urls.has
check has effectively been broken since then.This restores the
urls
map lookup with the "unresolved"file
, and allowsgetCodeFrame
to skip trying to read the nonsense path. The runtime result is the same either way -getCodeFrame
moves on to the next frame in the stack, but no error should be logged to console.Supersedes #841
Changelog: [Fix] Don't log ENOENT errors to console for expected URL stack frames
Test plan
Before
Added failing tests to
Server-test.js
:After