Salesforce source: incremental sync reports "Completed" while the table is silently frozen (per-batch type inference, string vs double merge failure)

[patrykkarny]

Bug Description

We run the Salesforce connector (data warehouse, pipeline v3) on PostHog Cloud US. Since 2026-08-20 the incremental sync of our Lead schema has been frozen: every 6-hourly run reports status Completed with a constant rows_synced value, but the incremental cursor never advances and zero rows land in the table. We only noticed because a downstream dashboard stopped moving.

The sync logs show that every one of those "Completed" runs actually failed extraction (field names redacted, exact logs shared via in-app support):

INFO   V3 Pipeline: Extraction starting
ERROR  V3 Pipeline: Extraction failed
ERROR  Unable to merge: Field <number_field_1>_c has incompatible types: string vs double
INFO   V3 Pipeline: Resumable source detected - attempting to resume previous import
INFO   deltalite write: committed [Lead]
INFO   batch_processed_ok [Lead] #0
INFO   Updated external data job … to status Completed

The retry takes the resumable-source path, commits a no-op batch and the job gets stamped Completed. The ArrowTypeError only ever appears in the log stream.

Root cause, as far as we can tell: column types are inferred per batch from the values present, not from Salesforce field metadata. The Salesforce source pulls SELECT FIELDS(ALL) … LIMIT 200 and never calls describe, so a batch where a Salesforce Number field is entirely NULL infers null → string, which then can't merge with double from another batch. Two observations support this:

• the merge errors fire in both directions on the same fields (double vs string and string vs double) across attempts, which rules out the destination table's type acting as the referee;
• the incremental window that froze our sync contained exactly 2 records, and every Number field on both was NULL (verified in Salesforce with SOQL).

Full resync does not recover it: 4 attempts all failed during extraction with the same error class, each time on a different Number field. One run burned 12 Temporal attempts across 6 different fields. Excluding fields via enabled_columns just moves the failure to the next Number field; our Lead object has ~40 nullable numeric fields, so an allowlist can't win.

One column is also permanently mistyped in the destination: a Number(18,0) field in Salesforce is stored as string in the Delta table, presumably because an all-null batch won the type race when the table was first materialized.

Related work in this repo:

• fix(data-imports): stabilize column types across extract batches #75819 (open, currently stale-flagged) describes this problem and would stabilize types within a run.
• fix(data-warehouse): stabilize CDC column types across micro-batches #66202 fixed the same class of bug for Postgres CDC by typing columns from the authoritative source type (the Postgres OID). Salesforce has authoritative types one describe call away, and SourceResponse.column_hints looks like the existing hook for it.
• fix(data-imports): promote numeric types when unifying v3 batch schemas #78432 added promote_options="permissive" to the batch writer, which covers int64↔double but not string↔double.

How to reproduce

1. Salesforce source, incremental sync on SystemModstamp, on an object with nullable Number fields.
2. Hit an incremental window whose rows are all NULL in one of those fields (a small batch of old or sparse records is enough).
3. The run fails extraction with ArrowTypeError, then reports Completed; the cursor never advances and every subsequent run reprocesses the same window.

Additional context

• The stuck runs were also billable, 4×/day, until we disabled the schedule ourselves.
• We've filed this through in-app support (Cloud US) with the project ID, source/schema/job ids, timestamps and unredacted logs — happy to connect this issue to that ticket. Opening the issue for visibility and linkability since we couldn't find an existing report of the Salesforce variant.

Beyond the type-inference fix, two asks: a run whose extraction raised should not surface as Completed (the silent staleness was the worst part of this for us), and some guidance on safely resetting a table whose column is now stored with the wrong type.

Debug info

- [x] PostHog Cloud, region and project ID: US; project ID shared via in-app support ticket