PR Summary

Medium Risk
Touches deploy-time trigger validation for webhook configuration; mistakes could allow missing config through or block valid deployments, but the change is localized and uses existing canonical grouping logic.

Overview
Fixes a deploy-time validation bug where triggers with canonical basic/advanced paired fields could fail with “Missing required fields” even when one side of the pair was set.

buildProviderConfig now builds a canonical index and performs a two-pass scan: first collecting provided values and marking satisfied canonical groups, then only flagging required fields as missing when no member of a canonical group has a value.

^{Reviewed by Cursor Bugbot for commit c7ae3ef. Configure here.}

Greptile Summary

This PR fixes a bug in buildProviderConfig where canonical-paired subblock twins (e.g., a file-selector spreadsheetId and its manual-input manualSpreadsheetId) were both validated independently for required fields. The fix introduces a two-pass approach: the first pass collects all non-empty values and marks canonical groups as satisfied, and the second pass skips the required-field check for any subblock whose canonical group was already satisfied by another member.

Confidence Score: 5/5

Safe to merge — targeted bug fix with correct two-pass canonical validation logic and no regressions introduced.

The change is minimal and well-scoped: it adds buildCanonicalIndex (an already-tested utility) and rewrites only the required-field validation logic in buildProviderConfig. The two-pass approach correctly handles both the satisfied-group skip and the pre-existing value-collection behavior. No P0 or P1 issues were found.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[buildProviderConfig called] --> B[buildCanonicalIndex from triggerDef.subBlocks]
    B --> C[Filter relevantSubBlocks\nmode: trigger or trigger-advanced]
    C --> D["Pass 1: Collect values\n(iterate relevantSubBlocks)"]
    D --> E{subBlock has\nnon-empty value?}
    E -- Yes --> F[Add to providerConfig]
    F --> G{Has canonicalParamId?}
    G -- Yes --> H[Mark canonicalId\nas satisfied]
    G -- No --> I[Continue]
    H --> I
    E -- No --> I
    I --> J{More subBlocks?}
    J -- Yes --> D
    J -- No --> K["Pass 2: Validate required fields\n(iterate relevantSubBlocks)"]
    K --> L{Value already\nin providerConfig?}
    L -- Yes --> M[Skip - continue]
    L -- No --> N{In a satisfied\ncanonical group?}
    N -- Yes --> M
    N -- No --> O{isFieldRequired?}
    O -- Yes --> P[Add to missingFields]
    O -- No --> Q[Continue]
    P --> Q
    Q --> R{More subBlocks?}
    R -- Yes --> K
    R -- No --> S[Return providerConfig\n+ missingFields]

_{Reviews (1): Last reviewed commit: "fix(trigger): skip canonical-paired memb..." | Re-trigger Greptile}

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 10, 2026 9:49pm

Addressed the Cursor Bugbot comment (discussion_r3066873288):

Bug confirmed. The second-pass guard providerConfig[subBlock.id] !== undefined was falsely satisfied by stale entries inherited from baseConfig (spread from triggerConfig at line 180). If a user had previously set a value for a required field and then cleared it, the leftover entry in triggerConfig would cause required-field validation to be silently skipped — allowing deployment with missing required fields.

Fix: Introduced a dedicated filledSubBlockIds: Set<string> that is populated only during the first pass from live getConfigValue results. The second-pass skip guard now checks filledSubBlockIds.has(subBlock.id) instead of providerConfig[subBlock.id] !== undefined, so stale baseConfig values can never mask a missing required field.

Pushed in commit 402462a.

Closing in favour of #4101 which includes all of these changes plus the broader polling trigger fixes — combined into a single PR since they're tightly coupled.