It looks like update txns don’t make sense on table-based syncs since the parquet files are unique. So update txns should behave effectively as if it were an append txn.
In our case, updated data will be added via append, then de-duplicated downstream of the sync by keeping the latest “record_created” time.