Fix "unexpected null" handling overlapping file changes #1083
Conversation
This file contains 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
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D49272782 |
Summary: Fixes a crash where a race in overlapping file change processing could occasionally throw "unexpected null". Fixes facebook#1015 ## Root cause The problem logic is in some instrumentation code introduced in D40346848. `metro-file-map` batches changes using `setInterval(emitChange, 30)`. The instrumentation attempted to record the time of the first event in a given batch, and then "reset the clock" when the batch is emitted to the consumer. The problem occurred when an emit interval fell such that a non-empty `emitChange` occurred *during* the async `_processFile` step of a subsequent change. The first emit would reset the "start time" to `null`, and the second `emitChange` would fail at `nullthrows(eventStartTimestamp)`, because `eventStartTimestamp` is only set *before* `_processFile` starts (and only if already `null`). The (over)writing of `eventStartTimestamp` was flawed, because we don't know at the start of change processing that this event is going to be the start of a batch - this only becomes clear when an event is subsequently enqueued for emit after file processing. ## This diff This changes the recording of the start time such that we take a timestamp on every change, and record it as the batch start time on the creation of a new batch. We rearrange the various moving parts into a nullable object, so that "first event time" is tightly coupled to the batch it describes, and can never be `null` for a non-empty batch. ## Changelog ``` * **[Fix]:** Fix "unexpected null" crash when handling a batch of file changes. ``` Differential Revision: D49272782
robhogan
force-pushed
the
export-D49272782
branch
from
695ae1e
to
b8c2cad
Compare
|
This pull request was exported from Phabricator. Differential Revision: D49272782 |
|
This pull request has been merged in 75f3927. |
robhogan
added a commit
that referenced
this pull request
Jan 9, 2024
Summary: Pull Request resolved: #1083 Fixes a crash where a race in overlapping file change processing could occasionally throw "unexpected null". Fixes #1015 ## Root cause The problem logic is in some instrumentation code introduced in D40346848. `metro-file-map` batches changes using `setInterval(emitChange, 30)`. The instrumentation attempted to record the time of the first event in a given batch, and then "reset the clock" when the batch is emitted to the consumer. The problem occurred when an emit interval fell such that a non-empty `emitChange` occurred *during* the async `_processFile` step of a subsequent change. The first emit would reset the "start time" to `null`, and the second `emitChange` would fail at `nullthrows(eventStartTimestamp)`, because `eventStartTimestamp` is only set *before* `_processFile` starts (and only if already `null`). The (over)writing of `eventStartTimestamp` was flawed, because we don't know at the start of change processing that this event is going to be the start of a batch - this only becomes clear when an event is subsequently enqueued for emit after file processing. ## This diff This changes the recording of the start time such that we take a timestamp on every change, and record it as the batch start time on the creation of a new batch. We rearrange the various moving parts into a nullable object, so that "first event time" is tightly coupled to the batch it describes, and can never be `null` for a non-empty batch. ## Changelog ``` * **[Fix]:** Fix "unexpected null" crash when handling a batch of file changes. ``` Reviewed By: huntie Differential Revision: D49272782 fbshipit-source-id: 8e1a4ebb6876fad982af3aa8a1922c6f14236040
Merged
siddarthkay
added a commit
to status-im/status-mobile
that referenced
this pull request
Jan 12, 2024
### Summary Metro server often crashes with ``` status-mobile/node_modules/nullthrows/nullthrows.js:9 throw error; ^ Error: Got unexpected null ``` This commit resolves metro to a commit where this specific issue was fixed. related PR in metro repo : facebook/metro#1083
robhogan
added a commit
that referenced
this pull request
Jan 30, 2024
Summary: Pull Request resolved: #1083 Fixes a crash where a race in overlapping file change processing could occasionally throw "unexpected null". Fixes #1015 ## Root cause The problem logic is in some instrumentation code introduced in D40346848. `metro-file-map` batches changes using `setInterval(emitChange, 30)`. The instrumentation attempted to record the time of the first event in a given batch, and then "reset the clock" when the batch is emitted to the consumer. The problem occurred when an emit interval fell such that a non-empty `emitChange` occurred *during* the async `_processFile` step of a subsequent change. The first emit would reset the "start time" to `null`, and the second `emitChange` would fail at `nullthrows(eventStartTimestamp)`, because `eventStartTimestamp` is only set *before* `_processFile` starts (and only if already `null`). The (over)writing of `eventStartTimestamp` was flawed, because we don't know at the start of change processing that this event is going to be the start of a batch - this only becomes clear when an event is subsequently enqueued for emit after file processing. ## This diff This changes the recording of the start time such that we take a timestamp on every change, and record it as the batch start time on the creation of a new batch. We rearrange the various moving parts into a nullable object, so that "first event time" is tightly coupled to the batch it describes, and can never be `null` for a non-empty batch. ## Changelog ``` * **[Fix]:** Fix "unexpected null" crash when handling a batch of file changes. ``` Reviewed By: huntie Differential Revision: D49272782 fbshipit-source-id: 8e1a4ebb6876fad982af3aa8a1922c6f14236040
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.
Summary:
Fixes a crash where a race in overlapping file change processing could occasionally throw "unexpected null".
Root cause
The problem logic is in some instrumentation code introduced in D40346848.
metro-file-mapbatches changes usingsetInterval(emitChange, 30). The instrumentation attempted to record the time of the first event in a given batch, and then "reset the clock" when the batch is emitted to the consumer.The problem occurred when an emit interval fell such that a non-empty
emitChangeoccurred during the async_processFilestep of a subsequent change. The first emit would reset the "start time" tonull, and the secondemitChangewould fail atnullthrows(eventStartTimestamp), becauseeventStartTimestampis only set before_processFilestarts (and only if alreadynull).The (over)writing of
eventStartTimestampwas flawed, because we don't know at the start of change processing that this event is going to be the start of a batch - this only becomes clear when an event is subsequently enqueued for emit after file processing.This diff
This changes the recording of the start time such that we take a timestamp on every change, and record it as the batch start time on the creation of a new batch. We rearrange the various moving parts into a nullable object, so that "first event time" is tightly coupled to the batch it describes, and can never be
nullfor a non-empty batch.Changelog
Differential Revision: D49272782