This PR helps ensure progress is reported before beginning cutover.
Ghostferry, as a library, can't enforce or ensure that clients don't terminate/error-out during cutover. Custom code leaves this as a possibility.
Before notifying clients that row copy is complete, we should dispatch a progress callback.
This conditional change comes before the notification (notifyRowCopyCompletion), to avoid any possible race conditions. If the notification of row completion occurs first, the client (ex: copydb, sharding) could execute, and possibly fail, before the progress callback is emitted.
Testing
I've add an integration test for this specific use case. Namely, simulate a Ghostferry client that is killed after row copy complete has finished.
Assertions are put in place to now make sure that – even in this case – progress is reported.
Closes #232
What was done?
This PR helps ensure progress is reported before beginning cutover.
Ghostferry, as a library, can't enforce or ensure that clients don't terminate/error-out during cutover. Custom code leaves this as a possibility.
Before notifying clients that row copy is complete, we should dispatch a progress callback.
This conditional change comes before the notification (
notifyRowCopyCompletion), to avoid any possible race conditions. If the notification of row completion occurs first, the client (ex:copydb,sharding) could execute, and possibly fail, before the progress callback is emitted.Testing
I've add an integration test for this specific use case. Namely, simulate a Ghostferry client that is killed after row copy complete has finished.
Assertions are put in place to now make sure that – even in this case – progress is reported.
I've manually tested it out as well.