[BUG] Breaking change regarding Google Sheets in PD Connect setting

[mariczne]

Describe the bug
The Google Sheets New Row Added (Instant) (google_sheets-new-row-added) source now changes the type/shape of the emitted newRow field based on a Pipedream-owned UI toggle (Has Headers).

• Has Headers = OFF: newRow is an array (as it was).
• Has Headers = ON: newRow becomes an object keyed by column names.
  This silently breaks downstream mappings that expect an array, including integrations embedded via Pipedream Connect. While adding a new option might appear non-breaking, we use your connect-react SDK, which automatically exposes/permits these options in our embedded UI. End users can enable Has Headers without our code changes, which immediately alters the emitted schema and breaks our backend that expects the array.

The flip is visible in run logs: newRow changes from [...] to {...} after toggling Has Headers.

Additional context

• Impact: This is breaking for our users and our backend.

• Again, let me stress why this is breaking even if it “adds an option”: While adding a new option might appear non-breaking, we use your connect-react SDK, which automatically exposes/permits these options in our embedded UI. End users can enable Has Headers without our code changes, which immediately alters the emitted schema and breaks our backend that expects the array.

• Severity: High — production flows can fail or mis-map data without any deployment on our side.

• Connect partner stability — policy clarification needed:

  • Do you consider this change non-breaking for Connect? It is clearly breaking for users that use the provided Connect React SDK.
  • What is the deprecation/notification process before user-facing toggles can alter emitted schemas?
  • Are Connect partners expected to monitor PRs to avoid breakage, or will you provide a dedicated partner changelog/early-access channel with minimum notice? This PR was created and merged within a span of ~15 hours.
  • What is your idea of partner contract in the future (compat flags, semver for sources, migration windows, UI warnings) so end-user toggles cannot break embedded integrations?

This being triggerable by an end-user control in Pipedream’s UI is a significant issue for Connect partners relying on schema stability, especially considering we still don't have version pinning AFAIK.

Related:
#18278
#18327

Tagging @jcortes, @dannyroosevelt

[mariczne]

The PR #18327 in general seems rushed and optimistic in its solution. We already considered these points that I'm going to mention since we've been integrating with spreadsheets primarily.

Apart from the unexpected payload shape change:

• Header-based mapping only remains correct if column names don’t change. Renaming a header silently changes the emitted object’s keys and breaks downstream consumers; only reordering is safe. Although in PD's case headers are cached, too, so I guess renaming doesn't matter, but reordering breaks?
• Repeated header names map to the same object key, so later columns overwrite earlier ones. There’s no disambiguation in the current approach.
• Most important: Header-based mapping can imply “schema” stability in a free-form sheet. In reality, end-users can type anything anywhere; the feature can create a false sense of safety compared to explicit positional addressing (it is, so to speak, not "true" at any given time, compared to indices).

[mariczne]

We patched the issue quickly on our end, but we'd really rather not have surprises like that. I'd be grateful for clarifying the policies regarding code stability mentioned in the original post.

I see ComponentFormContainer supports propNames attribute that could prevent us from having a surprise new props, which would help in this case. We'll definitely lock the propNames we use. What about other cases?

[jcortes]

Hi @mariczne thanks for submitting this issue. I've just pushed a new PR here so let me know if that solves the issue thanks!

[mariczne]

Hello @jcortes, thank you for the PR. This is definitely an improvement 👍 We already adapted to the changes but this would be better for other affected users I think, so we can adapt as well.