Conversation
kdhillon-stripe
left a comment
There was a problem hiding this comment.
can we add a test case in the e2e test for this?
fc93632 to
3483d62
Compare
added |
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| entries: Record<string, any>[], |
There was a problem hiding this comment.
i see all of the other helper fns have this too
| 'deleted', | ||
| ]) |
There was a problem hiding this comment.
do we need this anymore? it should not be needed after #347
There was a problem hiding this comment.
i suppose the real fix is to stack this pr on that
There was a problem hiding this comment.
Yes, because some objects do have deleted fields in their openAPI schema. (in discussion with tony & steven we decided to drop the column completely)
| >() { | ||
| return { | ||
| record(payload: { stream: string; data: TRecordData; emitted_at: string }): RecordMessage { | ||
| record(payload: { stream: string; data: TRecordData; emitted_at: string, recordDeleted?: boolean }): RecordMessage { |
There was a problem hiding this comment.
not blocking: i wonder if this is better represented as a special type of TRecordData. if it's deleted, the data itself is { ..., deleted:true }
There was a problem hiding this comment.
data.deleted was stripped by enforceCatalog, that was partially causing some issues that Steven noticed with webhookds
Summary
Switches the Postgres destination from soft delete to hard delete. When a record arrives with deleted: true, the matching row is physically removed from the destination table instead of being upserted with a deleted flag.
Changes
packages/destination-postgres
Backward compatibility
Existing soft-deleted rows from prior deployments are intentionally not cleaned up. no production user is on the soft-delete code path, so we don't need a migration.
Tested
Manual end-to-end: backfill a Stripe account with deletes (delete a customer in the dashboard) and confirm the row disappears from the destination.