Repository navigation
Conversation
…Error #1949 records what a successful resolution observes of the file system, but a resolution that fails throws and its record is discarded. A failed import depends on the file system just as much - creating the missing file, or a `package.json` that redirects to it, can make it resolve - so anything that wants to know when to retry needs the same record. This attaches it to `UnableToResolveError` as `unstable_observations`. With `unstable_incrementalResolution` on, it's the record from the failed attempt. With it off, Metro replays the failure once with a fresh record. That's sound because resolution is synchronous and observes the file system only through the capabilities bound to the record, so the replay sees the same state and fails the same way. It costs one extra resolution per failure, and only for failures that break the build. Optional dependencies aren't replayed, since their failures are expected and they re-resolve on every traversal. If a replay succeeds, a custom resolver is reading something outside its resolution context. Metro warns about that and throws the original error, without observations. Within Metro, a hard failure already retries on the next change because `DeltaCalculator` keeps the module pending, so nothing here reads the record yet. It's a draft to settle the shape of the API. Changelog: Internal Test plan: New unit tests.
meta-cla
Bot
added
the
CLA Signed
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
#1949 records what a successful resolution observes of the file system, but a resolution that fails throws and its record is discarded. A failed import depends on the file system just as much - creating the missing file, or a
package.jsonthat redirects to it, can make it resolve - so anything that wants to know when to retry needs the same record.This attaches it to
UnableToResolveErrorasunstable_observations. Withunstable_incrementalResolutionon, it's the record from the failed attempt. With it off, Metro replays the failure once with a fresh record. That's sound because resolution is synchronous and observes the file system only through the capabilities bound to the record, so the replay sees the same state and fails the same way. It costs one extra resolution per failure, and only for failures that break the build.Optional dependencies aren't replayed, since their failures are expected and they re-resolve on every traversal. If a replay succeeds, a custom resolver is reading something outside its resolution context. Metro warns about that and throws the original error, without observations.
Within Metro, a hard failure already retries on the next change because
DeltaCalculatorkeeps the module pending, so nothing here reads the record yet. It's a draft to settle the shape of the API.Changelog: Internal
Test plan:
New unit tests.