Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix "unexpected null" handling overlapping file changes (#1083)
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
- Loading branch information