How to handle hard deletes that happened while Stitch wasn't running?

[vitorbaptista]

I have a MySQL RDS database that I track using Log-based Incremental, saving the results to a S3 bucket. It's working well, but a few times I reached the max number of rows replicated during a period, and Stitch stopped replicating for a period. During this period, some rows were hard deleted from the source MySQL RDS database. When Stitch was back up (after I upgraded my plan), it resumed replicating the data, but it didn't catch those hard deletions. In the end, these rows never get a _sdc_deleted_at column, even though they were deleted in the source DB.

How can I handle this? If I reset the table, will Stitch understand that some rows were deleted and add the _sdc_deleted_at? Or is there another way?

[vitorbaptista]

I tried resetting the table, but Stitch was unable to see the deleted rows. I ended up building a process where I check all IDs in my data warehouse and my source DB, and then delete the ones that don't appear in my source DB. It's very hackish, and I'd love to hear about a better solution.