Pipedrive warehouse sync crashes for field schema tables when generated subfields have null ids

Bug Description

Pipedrive Data Warehouse sync can fail for the field-schema tables:

• deal_fields
• organization_fields
• person_fields

In PostHog Cloud, the affected schema remains in Running with Rows synced = 0, and the job logs repeatedly show:

unsupported operand type(s) for //: 'NoneType' and 'int'

This appears to be caused by Pipedrive v1 field metadata returning generated subfield rows with id = null. These are normal Pipedrive metadata rows for complex/system fields, not malformed CRM records.

Examples of null-ID rows observed from Pipedrive v1 field endpoints:

• deal_fields: currency, weighted_value_currency, mrr_currency, arr_currency, acv_currency
• organization_fields: address_lat, address_long, address_subpremise, address_street_number, address_route
• person_fields: postal_address_lat, postal_address_long, postal_address_subpremise, postal_address_street_number, postal_address_route

Pipedrive v2 represents these as nested subfields under parent fields and identifies them with string field_code values rather than standalone numeric IDs.

How to reproduce

1. Configure a Pipedrive warehouse source where /api/v1/dealFields, /api/v1/personFields, or /api/v1/organizationFields returns generated subfield rows with id: null.
2. Enable/sync deal_fields, organization_fields, and/or person_fields.
3. The sync uses the default primary key id for these schemas.
4. If the id column is inferred as numeric but contains nulls, numerical partitioning reaches:

partition = row[key] // partition_size

and crashes when row[key] is None.

Additional context

The current Pipedrive source config uses v1 endpoints for the affected schemas and defaults primary_key to id:

• https://github.com/PostHog/posthog/blob/master/products/warehouse_sources/backend/temporal/data_imports/sources/pipedrive/settings.py#L13
• https://github.com/PostHog/posthog/blob/master/products/warehouse_sources/backend/temporal/data_imports/sources/pipedrive/settings.py#L31-L39

The source response then passes that primary key into the pipeline:

• https://github.com/PostHog/posthog/blob/master/products/warehouse_sources/backend/temporal/data_imports/sources/pipedrive/pipedrive.py#L188-L193

The partition helper can then choose numerical partitioning and crash on a nullable key:

• https://github.com/PostHog/posthog/blob/master/products/warehouse_sources/backend/temporal/data_imports/pipelines/pipeline/utils.py#L508-L512

Potential fixes:

1. Best connector fix: move Pipedrive field-schema syncs to v2 field endpoints and key by field_code, using parent field_code + subfield field_code for nested subfields.
2. Minimal connector fix: keep v1 endpoints but use key as the primary key for *_fields schemas instead of nullable id.
3. Generic pipeline safety fix: do not choose numerical partitioning when the selected partition key contains nulls; fall back to md5 or skip partitioning.

Debug info

• PostHog Cloud, Debug information: available privately if needed.
• Source type: Pipedrive
• Affected schemas: deal_fields, organization_fields, person_fields
• Cloud source/job URL: available privately if needed.

Start with products/warehouse_sources/backend/temporal/data_imports/sources/pipedrive/settings.py and pipedrive.py to trace the affected schemas and primary keys, then inspect products/warehouse_sources/backend/temporal/data_imports/pipelines/pipeline/utils.py around numerical partitioning. Decide between a connector-specific key or a generic nullable-key fallback, and verify that field-schema syncs complete without crashing on null IDs.