Uh oh!
There was an error while loading. Please reload this page.
fix(inputs): canonical params + manual validations + params resolution cleanups - #3141
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile OverviewGreptile SummaryFixed canonical parameter validation for OneDrive and Google Drive blocks by ensuring operation-specific canonical param IDs are used throughout. The changes address a bug where required field validation failed when using canonical parameters (basic/advanced mode pairs) because the serializer was checking the wrong field names. Key changes:
Confidence Score: 4/5
Important Files Changed
Sequence DiagramsequenceDiagram
participant User
participant UI as Block Editor UI
participant SubBlock as SubBlock Component
participant Serializer
participant BlockConfig as OneDrive/GoogleDrive Block
User->>UI: Select operation (e.g., "download")
UI->>SubBlock: Render file-selector with canonicalParamId="downloadFileId"
SubBlock->>SubBlock: buildCanonicalIndex() maps subBlock.id -> canonicalId
alt Basic Mode
User->>SubBlock: Select file from dropdown
SubBlock->>SubBlock: Store value in downloadFileSelector
else Advanced Mode
User->>SubBlock: Enter file ID manually
SubBlock->>SubBlock: Store value in downloadManualFileId
end
User->>UI: Execute workflow
UI->>Serializer: serialize(block, params)
Serializer->>Serializer: validateRequiredFields()
Note over Serializer: Check if subBlock is required
Serializer->>Serializer: Get canonicalId from canonicalIdBySubBlockId[subBlock.id]
Serializer->>Serializer: Look up params[canonicalId] instead of params[subBlock.id]
alt Value exists
Serializer->>BlockConfig: params.downloadFileId exists
BlockConfig->>BlockConfig: Resolve operation-specific fileId
BlockConfig-->>Serializer: Valid params with fileId
else Value missing
Serializer-->>UI: Error: "Missing required fields"
end
|
Additional Comments (5)
Prompt To Fix With AIThis is a comment left during a code review.
Path: apps/sim/blocks/blocks/onedrive.ts
Line: 183:183
Comment:
should be `'createFolderParentId'` to match the input declaration on line 411 and follow the same pattern as Google Drive
```suggestion canonicalParamId: 'createFolderParentId',```
How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix With AIThis is a comment left during a code review.
Path: apps/sim/blocks/blocks/onedrive.ts
Line: 204:204
Comment:
should be `'createFolderParentId'` to match the input declaration on line 411 and follow the same pattern as Google Drive
```suggestion canonicalParamId: 'createFolderParentId',```
How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix With AIThis is a comment left during a code review.
Path: apps/sim/blocks/blocks/onedrive.ts
Line: 261:261
Comment:
should be `'downloadFileId'` to match the input declaration on line 414 and follow the same pattern as Google Drive
```suggestion canonicalParamId: 'downloadFileId',```
How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix With AIThis is a comment left during a code review.
Path: apps/sim/blocks/blocks/onedrive.ts
Line: 283:283
Comment:
should be `'downloadFileId'` to match the input declaration on line 414 and follow the same pattern as Google Drive
```suggestion canonicalParamId: 'downloadFileId',```
How can I resolve this? If you propose a fix, please make it concise.
The function should:
Prompt To Fix With AIThis is a comment left during a code review.
Path: apps/sim/blocks/blocks/onedrive.ts
Line: 356:396
Comment:
this params function uses the old field IDs (`folderSelector`, `manualFolderId`, `fileSelector`, `manualFileId`) that no longer exist after the canonical param refactoring. It needs to be updated to destructure and handle the new canonical param IDs per-operation, similar to how Google Drive was fixed.
The function should:
1. Destructure the new canonical params like `uploadFolderId`, `listFolderId`, `createFolderParentId`, `downloadFileId`, `deleteFileId`2. Resolve `folderId` based on the operation type (upload/create_file → uploadFolderId, list → listFolderId, create_folder → createFolderParentId)
3. Resolve `fileId` based on the operation type (download → downloadFileId, delete → deleteFileId)
How can I resolve this? If you propose a fix, please make it concise. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
icecrasher321
commented
Feb 5, 2026
icecrasher321
commented
Feb 5, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
icecrasher321
commented
Feb 5, 2026
@cursor review |
Uh oh!
There was an error while loading. Please reload this page.
…n cleanups (simstudioai#3141) * fix(onedrive): canonical param required validation * fix onedrive * cleanup canonical tool param resolution code * fix type * fix jira type checks * remove manual validations
…potency - verifyAuth now rejects with 401 when no token is configured instead of silently allowing unauthenticated requests through - formatInput falls back to the legacy formId providerConfig key (pre-#3141 rename to triggerFormId) so old deployments keep working - add extractIdempotencyId keyed on formId:responseId to dedupe retried Apps Script deliveries
…potency - verifyAuth now rejects with 401 when no token is configured instead of silently allowing unauthenticated requests through - formatInput falls back to the legacy formId providerConfig key (pre-#3141 rename to triggerFormId) so old deployments keep working - add extractIdempotencyId keyed on formId:responseId to dedupe retried Apps Script deliveries
…potency (#5377) - verifyAuth now rejects with 401 when no token is configured instead of silently allowing unauthenticated requests through - formatInput falls back to the legacy formId providerConfig key (pre-#3141 rename to triggerFormId) so old deployments keep working - add extractIdempotencyId keyed on formId:responseId to dedupe retried Apps Script deliveries
Summary
Type of Change
Testing
Tested manually
Checklist