How does gh-ost guarantee no race between chunk copying & binlog processing

Hi folks,

Thank you all for writing this awesome tool! There's one scenario I don't quite understand. How do we avoid following situation:

1) A row in the original table has value (foo, 1).
2) A migration run starts: (foo, 1) is read by the chunk copying thread, but before it's written into the ghost table, 3) & 4) happened.
3) A user of the table updates the row and changes its value to (bar, 2)
4) Binlog of the update is processed, (bar, 2) is not written into the ghost table because of the query condition.
5) the execution of 2) is now resumed, and (foo, 1) is written into the ghost table.

The issue of this scenario is that after 5), the row has incorrect value, and it's not fixable by future binlog entries (because it won't match the update query condition)

Best,
Zhe