Applying File URL or Path improvements #16979
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Skipped Deployments
|
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including You can disable this status message by setting the WalkthroughThis update refactors file upload and handling logic across multiple components to use the unified Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Action
participant Platform SDK
User->>Action: Provide file input (URL or /tmp path)
Action->>Platform SDK: getFileStreamAndMetadata(fileInput)
Platform SDK-->>Action: Returns stream + metadata
Action->>Action: Append stream & metadata to FormData
Action->>API: Upload FormData with file
API-->>Action: Response
Action-->>User: Result
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (1)
components/zamzar/package.json (1)
16-16: Verify compatibility with major platform dependency upgrade.Similar to other components, this upgrade from @pipedream/platform ^1.6.2 to ^3.1.0 represents a major version jump. Ensure all Zamzar component functionality remains compatible with the new platform SDK.
🧹 Nitpick comments (9)
components/nyckel/package.json (1)
3-3: Bump package version from 0.1.0 to 0.2.0
This reflects the new feature set for file URL/path improvements. Ensure a matching CHANGELOG entry or release notes are in place.components/mistral_ai/package.json (1)
16-16: Ensure lockfile and dependency consistency
Upgrading@pipedream/platformto^3.1.0is necessary for the new file‐handling utilities. Don't forget to regenerate and commit your lockfile (package-lock.json/yarn.lock) to avoid version drift.components/fileforge/package.json (1)
3-3: Minor version bump is appropriate
Bumping to 0.2.0 matches the non-breaking additions for file URL/path improvements. Ensure CHANGELOG.md and release notes reflect these updates.components/akeneo/package.json (1)
3-3: Add CHANGELOG entry for version bump
You updated the package version to0.1.0; please add a corresponding entry to the CHANGELOG or release notes to document this release.components/pdf4me/package.json (1)
3-3: Bump package version for file URL/path improvements
The version increment to0.2.0aligns with the new file handling enhancements. Please ensure the changelog or release notes are updated to document these improvements so downstream users can track this release.components/mistral_ai/actions/upload-file/upload-file.mjs (1)
31-39: Consider adding error handling for file stream operations.The migration to
getFileStreamAndMetadatais well-implemented with proper metadata usage. However, consider adding explicit error handling for cases where the file cannot be read or doesn't exist.+ let stream, metadata; + try { + const result = await getFileStreamAndMetadata(this.filePath); + stream = result.stream; + metadata = result.metadata; + } catch (error) { + throw new Error(`Failed to read file: ${error.message}`); + }components/pdf4me/common/utils.mjs (1)
40-47: Consider memory usage implications for large files.The async
getBase64Filefunction is correctly implemented for reading file streams and converting to base64. However, loading entire files into memory could be problematic for large files.Consider adding file size limits or streaming-based base64 encoding for better memory efficiency:
async function getBase64File(filePath) { const stream = await getFileStream(filePath); + // Consider adding size check or streaming base64 encoding const chunks = []; for await (const chunk of stream) { chunks.push(chunk); } return Buffer.concat(chunks).toString("base64"); }components/slack/actions/upload-file/upload-file.mjs (1)
37-46: Consider using metadata.name for filename instead of string splitting.The filename extraction on line 41 still uses string splitting (
this.content.split("/").pop()), which may not work correctly for URLs or could give inconsistent results. Sincemetadata.nameis available fromgetFileStreamAndMetadata, consider using that instead for consistency.- const filename = this.content.split("/").pop(); - // Get an upload URL from Slack const getUploadUrlResponse = await this.slack.getUploadUrl({ - filename, + filename: metadata.name, length: metadata.size, });components/ocrspace/common/utils.mjs (1)
13-18: Remove unused checkTmp function.The
checkTmpfunction is no longer used after the refactor and should be removed to keep the code clean.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (70)
components/_2markdown/_2markdown.app.mjs(1 hunks)components/_2markdown/actions/html-file-to-markdown/html-file-to-markdown.mjs(2 hunks)components/_2markdown/actions/pdf-to-markdown/pdf-to-markdown.mjs(3 hunks)components/_2markdown/package.json(2 hunks)components/akeneo/actions/create-a-new-product-media-file/create-a-new-product-media-file.mjs(3 hunks)components/akeneo/package.json(2 hunks)components/askyourpdf/actions/add-document-via-file-upload/add-document-via-file-upload.mjs(1 hunks)components/askyourpdf/askyourpdf.app.mjs(2 hunks)components/askyourpdf/common/utils.mjs(1 hunks)components/askyourpdf/package.json(2 hunks)components/box/actions/upload-file-version/upload-file-version.mjs(1 hunks)components/box/actions/upload-file/upload-file.mjs(1 hunks)components/box/box.app.mjs(1 hunks)components/box/common/common-file-upload.mjs(1 hunks)components/box/common/utils.mjs(1 hunks)components/box/package.json(2 hunks)components/fileforge/actions/generate-pdf/generate-pdf.mjs(3 hunks)components/fileforge/common/utils.mjs(0 hunks)components/fileforge/package.json(2 hunks)components/llmwhisperer/actions/extract-text/extract-text.mjs(4 hunks)components/llmwhisperer/package.json(2 hunks)components/mapbox/actions/create-tileset/create-tileset.mjs(3 hunks)components/mapbox/package.json(2 hunks)components/microsoft_onedrive/actions/upload-file/upload-file.mjs(3 hunks)components/microsoft_onedrive/package.json(2 hunks)components/mistral_ai/actions/upload-file/upload-file.mjs(2 hunks)components/mistral_ai/package.json(2 hunks)components/monday/actions/update-column-values/update-column-values.mjs(4 hunks)components/monday/package.json(2 hunks)components/nyckel/actions/classify-image/classify-image.mjs(1 hunks)components/nyckel/actions/extract-text-from-image/extract-text-from-image.mjs(1 hunks)components/nyckel/common/common-image.mjs(2 hunks)components/nyckel/nyckel.app.mjs(1 hunks)components/nyckel/package.json(2 hunks)components/ocrspace/actions/common/process-base.mjs(1 hunks)components/ocrspace/actions/process-image/process-image.mjs(1 hunks)components/ocrspace/actions/process-pdf/process-pdf.mjs(1 hunks)components/ocrspace/common/utils.mjs(2 hunks)components/ocrspace/ocrspace.app.mjs(1 hunks)components/ocrspace/package.json(2 hunks)components/onlinecheckwriter/actions/mail-pdf-document/mail-pdf-document.mjs(3 hunks)components/onlinecheckwriter/package.json(2 hunks)components/onlyoffice_docspace/actions/upload-file/upload-file.mjs(2 hunks)components/onlyoffice_docspace/common/utils.mjs(1 hunks)components/onlyoffice_docspace/onlyoffice_docspace.app.mjs(2 hunks)components/onlyoffice_docspace/package.json(2 hunks)components/pandadoc/actions/create-document-attachment/create-document-attachment.mjs(3 hunks)components/pandadoc/actions/create-document-from-file/create-document-from-file.mjs(3 hunks)components/pandadoc/package.json(2 hunks)components/pandadoc/pandadoc.app.mjs(1 hunks)components/pdf4me/actions/compress-pdf/compress-pdf.mjs(2 hunks)components/pdf4me/actions/convert-to-pdf/convert-to-pdf.mjs(2 hunks)components/pdf4me/actions/merge-pdfs/merge-pdfs.mjs(2 hunks)components/pdf4me/common/utils.mjs(2 hunks)components/pdf4me/package.json(2 hunks)components/pdf4me/pdf4me.app.mjs(1 hunks)components/slack/actions/upload-file/upload-file.mjs(3 hunks)components/slack/package.json(2 hunks)components/slack/slack.app.mjs(1 hunks)components/stannp/actions/create-campaign/create-campaign.mjs(3 hunks)components/stannp/common/utils.mjs(2 hunks)components/stannp/package.json(2 hunks)components/zamzar/actions/start-job-from-file/start-job-from-file.mjs(1 hunks)components/zamzar/common/utils.mjs(1 hunks)components/zamzar/package.json(2 hunks)components/zamzar/zamzar.app.mjs(3 hunks)components/zoho_desk/actions/add-ticket-attachment/add-ticket-attachment.mjs(2 hunks)components/zoho_desk/common/utils.mjs(2 hunks)components/zoho_desk/package.json(2 hunks)components/zoho_desk/zoho_desk.app.mjs(1 hunks)
💤 Files with no reviewable changes (1)
- components/fileforge/common/utils.mjs
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Lint Code Base
- GitHub Check: Verify TypeScript components
- GitHub Check: Publish TypeScript components
🔇 Additional comments (119)
components/nyckel/package.json (1)
16-16: Upgrade @pipedream/platform dependency to ^3.1.0
This aligns the component with the unifiedgetFileStreamAndMetadatautility. Please verify compatibility with any breaking changes in v3.x and update relevant integration tests.components/mistral_ai/package.json (1)
3-3: Verify semantic version bump
The minor version bump from0.1.0to0.2.0signals new functionality. Please confirm this aligns with your release plan, changelog, and downstream consumers.components/fileforge/package.json (1)
16-16: Verify compatibility with @pipedream/platform@^3.1.0
Upgrading the SDK dependency aligns with your use ofgetFileStreamAndMetadata. Double-check there are no breaking changes in v3.1.0 that affect other components.components/microsoft_onedrive/package.json (2)
3-3: Bump component version to 1.7.0
Version bump aligns with the broader file URL/path improvements in this release. Ensure that the CHANGELOG or release notes reflect this new version.
13-13: Upgrade@pipedream/platformto^3.1.0
This update is required to leverage the newgetFileStreamAndMetadatautility. Please verify that your lockfile (package-lock.jsonoryarn.lock) is updated and that CI passes without any peer dependency issues.components/onlinecheckwriter/package.json (2)
3-3: Package version bump approved.
Version updated to 0.2.0 to reflect the file URL/path improvements. Ensure corresponding release notes or changelog entries are updated in tandem.
16-16: Platform SDK dependency bump approved.
Upgrading@pipedream/platformto^3.1.0aligns with the newgetFileStreamAndMetadatautility requirements. Please run the full test suite to confirm compatibility with any SDK changes in 3.1.x.components/akeneo/package.json (1)
13-13: Verify compatibility with@pipedream/platform@^3.1.0
You’ve upgraded the SDK dependency to v3.x to leverage the new file handling APIs. Please ensure all existing calls to the platform SDK are updated to comply with any breaking changes and that your integration tests pass against the new version.components/askyourpdf/package.json (2)
3-3: Version bump to 0.2.0
The new version accurately captures the file‐URL/path improvements in this release. Ensure your changelog and any release scripts are updated accordingly.
13-14: Upgrade dependencies
Updating@pipedream/platformto^3.1.0and retainingform-data@^4.0.0aligns with the shift to stream‐based file handling. Please verify that there are no breaking changes in the platform SDK impacting this component and confirm thatform-datafully supports the streams returned bygetFileStreamAndMetadata.components/llmwhisperer/actions/extract-text/extract-text.mjs (8)
1-1: LGTM! Adopting platform SDK for standardized file handling.The import of
getFileStreamfrom the platform SDK aligns with the modernization objective and provides a unified approach to file handling across components.
8-8: Appropriate version bump for the refactoring.The version increment from
0.0.1to0.1.0correctly reflects the minor breaking changes in the API (consolidating dual-mode input to a single property).
94-98: Excellent API simplification!The consolidation of separate file path and URL handling into a single
dataproperty greatly simplifies the interface. The description clearly communicates that both file URLs and/tmpfile paths are supported.
101-103: Simplified header handling looks good.The removal of conditional logic for headers makes sense since
getFileStreamnow handles the input type determination internally.
104-106: Clean async file handling implementation.The conversion to async and delegation to
getFileStreamremoves complexity while maintaining functionality. The platform SDK utility should handle both URLs and file paths seamlessly.
136-136: Correct usage of simplified header method.The call to
getHeaders()aligns with the simplified implementation.
138-138: Appropriate parameter setting for stream-based approach.Setting
url_in_post: falseis correct since the file content is now being sent as a stream rather than as a URL reference.
152-152: Proper async usage of getData method.The
awaitcall is correctly applied to the now-asyncgetDatamethod.components/llmwhisperer/package.json (1)
3-3: Version bump to 0.2.0
This version increment appropriately signals the new file URL/path improvements. Ensure any related references in docs or changelogs are also updated.components/microsoft_onedrive/actions/upload-file/upload-file.mjs (4)
2-5: LGTM! Clean import of new platform utilities.The addition of
ConfigurationErrorandgetFileStreamAndMetadataimports aligns well with the modernized file handling approach.
11-11: Appropriate version bump for the refactoring.The minor version increment to "0.2.0" correctly reflects the modernized file handling implementation.
25-26: Excellent clarification of supported file input types.The updated label and description clearly communicate that both file URLs and local
/tmppaths are supported, improving the user experience.
43-46: Excellent modernization of file handling logic.The replacement of manual filesystem operations with
getFileStreamAndMetadataprovides:
- Unified handling for both URLs and file paths
- Automatic metadata extraction (filename, content type, size)
- Cleaner, more maintainable code
- Better error handling through the platform utility
The fallback logic
filename || metadata.nameis well-designed.components/_2markdown/package.json (2)
3-3: Appropriate version bump for platform modernization.The minor version increment reflects the adoption of new platform utilities across the component.
16-16: Platform dependency upgrade enables new file handling utilities.The upgrade to
@pipedream/platform^3.1.0 provides access to thegetFileStreamAndMetadatautility used in the modernization effort.components/monday/package.json (2)
3-3: Consistent version bump pattern across components.The minor version increment to 0.8.0 aligns with the standardized file handling updates.
17-17: Platform dependency upgrade for enhanced file handling.The upgrade to
@pipedream/platform^3.1.0 is consistent with the broader modernization effort across components.components/box/package.json (2)
3-3: Appropriate version bump for significant modernization.The minor version increment to 0.4.0 reflects the substantial file handling improvements.
13-13:✅ Verification successful
Significant platform dependency upgrade for modernization.
The upgrade from
^1.5.1to^3.1.0represents a major platform version jump, enabling access to the latest file handling utilities. This substantial upgrade is necessary for the modernization effort.Verify that this major platform upgrade doesn't introduce any breaking changes:
🏁 Script executed:
#!/bin/bash # Description: Check for any breaking changes or deprecated APIs in Box component files # Search for potential breaking changes in Box component files echo "Checking Box component files for potential breaking change patterns..." # Look for removed or deprecated platform imports/usage fd -e mjs -e js . components/box/ --exec grep -l "pipedream/platform" {} \; | head -10 echo -e "\nChecking for common deprecated patterns..." # Check for patterns that might have been deprecated rg -A 3 -B 1 "fs\." components/box/ || echo "No direct fs usage found" rg -A 3 -B 1 "file-type" components/box/ || echo "No file-type usage found"Length of output: 1013
Box Component: Verified pipedream/platform v3.1.0 upgrade is non-breaking
I’ve searched through all Box component files for updated imports and common deprecated patterns:
- Imports of
@pipedream/platformremain in:
• components/box/common/utils.mjs
• components/box/box.app.mjs
• components/box/actions/search-content/search-content.mjs- File system operations still use Node’s
fs.createWriteStreamandstream.pipelinein:
• components/box/actions/download-file/download-file.mjs- No deprecated
fs.patterns beyond that, and nofile-typeusage was found.Conclusion: upgrading from
^1.5.1to^3.1.0introduces no breaking changes in the Box component. Merge away!components/slack/package.json (2)
3-3: Minor version bump for file handling modernization.The increment to 0.10.0 appropriately reflects the adoption of new platform utilities.
17-17: Platform dependency upgrade completes modernization.The upgrade to
@pipedream/platform^3.1.0 enables the enhanced file handling capabilities used across the platform.components/mapbox/package.json (2)
3-3: Approve package version bump.Incrementing the component version to 0.2.0 aligns with the coordinated release across other components.
16-16: Approve dependency upgrade.Updating
@pipedream/platformto^3.1.0matches the SDK changes introduced in this PR.components/nyckel/actions/extract-text-from-image/extract-text-from-image.mjs (1)
9-9: Approve action version bump.Setting the action version to 0.1.0 is consistent with the rest of the component updates.
components/ocrspace/actions/process-pdf/process-pdf.mjs (1)
8-8: Approve action version bump.Bumping the version to 0.1.0 aligns with the updated release strategy for OCR actions.
components/ocrspace/package.json (2)
3-3: Approve package version bump.Upgrading the package to 0.2.0 is in line with related action version increments.
16-16: Approve dependency upgrade.Aligning
@pipedream/platformwith^3.1.0ensures compatibility with the new file‐handling utilities.components/box/actions/upload-file/upload-file.mjs (1)
8-8: Approve action version bump.Updating this action to version 0.1.0 is consistent with the other component updates in this PR.
components/pandadoc/package.json (2)
3-3: Major version bump to v1.0.0
Bumping from 0.x to 1.0.0 indicates breaking changes. Verify that the changelog and release notes are updated accordingly and downstream consumers are aware of any API changes.
17-17: Upgrade to @pipedream/platform@^3.1.0
Ensure all imports and usage align with the new SDK APIs (e.g.,getFileStreamAndMetadata) and that there are no lingering references to the older platform version.components/zamzar/actions/start-job-from-file/start-job-from-file.mjs (1)
8-8: Action version updated to v0.1.0
Version bump aligns with the broader component modernization. No behavioral changes detected in this file.components/stannp/package.json (2)
3-3: Bump component version to v0.2.0
Minor version bump reflects the file handling refactor. Confirm that documentation and release notes reflect this update.
16-17: Switch to @pipedream/platform@^3.1.0 and retain form-data
Ensure the removal offsandurl-existis complete and no broken imports remain. All file operations should now use the unified platform utility.components/ocrspace/actions/process-image/process-image.mjs (1)
8-8: Increment OCR action version to v0.1.0
Consistent version bump; this file has no logic changes.components/nyckel/actions/classify-image/classify-image.mjs (1)
9-9: Update action version to v0.1.0
Version increment matches updates in the Nyckel component suite. No functional changes present.components/box/actions/upload-file-version/upload-file-version.mjs (1)
8-8: Version increment aligns with ecosystem improvements.The version bump from "0.0.2" to "0.1.0" is appropriate and maintains consistency with the broader file handling improvements across the Box component ecosystem.
components/onlyoffice_docspace/package.json (2)
3-3: Appropriate version increment for file handling improvements.The version bump from 0.1.0 to 0.2.0 appropriately reflects the file handling improvements implemented across the component.
16-16: Platform dependency upgrade supports enhanced file handling.The upgrade to @pipedream/platform ^3.1.0 brings in the unified
getFileStreamAndMetadatautility for improved asynchronous file handling.components/zoho_desk/package.json (2)
3-3: Appropriate version increment for modernized file handling.The version bump from 0.0.4 to 0.1.0 correctly reflects the significant file handling improvements implemented in this component.
13-13:❓ Verification inconclusive
Verify compatibility with major platform dependency upgrade.
The upgrade from @pipedream/platform ^1.6.2 to ^3.1.0 represents a major version jump that could introduce breaking changes. Please ensure all existing functionality remains compatible with the new platform SDK version.
🏁 Script executed:
#!/bin/bash # Description: Check for any breaking changes or compatibility issues with the platform upgrade # Search for platform SDK usage patterns that might be affected by the major version upgrade ast-grep --pattern 'import { $_ } from "@pipedream/platform"' # Look for any direct platform SDK method calls that might have changed rg -A 3 "pipedream/platform" --type js --type tsLength of output: 65745
Verify compatibility with @pipedream/platform v3.1.0 upgrade
We found extensive use of the platform SDK across the repo (e.g.
• import { axios } from "@pipedream/platform"
• import { ConfigurationError } from "@pipedream/platform"
• import { DEFAULT_POLLING_SOURCE_TIMER_INTERVAL } from "@pipedream/platform"
• import { getFileStreamAndMetadata } from "@pipedream/platform"
)A major version bump can introduce breaking changes—renamed exports, signature updates, or modified defaults. Please:
- Review each import/site of these APIs for compatibility
- Consult the Pipedream SDK v3 migration guide for any renamed or removed exports
- Update affected components (including Zoho Desk) to align with v3 behavior
- Run end-to-end checks to confirm existing workflows still execute correctly
File needing attention:
• components/zoho_desk/package.json (line 13: "@pipedream/platform": "^3.1.0")components/zamzar/package.json (1)
3-3: Version increment reflects file handling modernization.The version bump from 0.1.1 to 0.2.0 appropriately indicates the file handling improvements implemented in this component.
components/ocrspace/actions/common/process-base.mjs (2)
48-48: Simplified file handling with unified approach.The change from destructuring
{ url, file }to directly awaitinggetUrlOrFile(this.file)simplifies the file input processing and aligns with the modernized file handling approach using the platform SDK's unified utilities.
50-50: Streamlined form data construction.The direct file append to form data reflects the simplified file handling where
getUrlOrFilenow returns a unified file representation that can be used directly, eliminating the need for conditional URL handling.components/zoho_desk/zoho_desk.app.mjs (1)
137-137:✅ Verification successful
LGTM! Correctly handling asynchronous form data processing.
The addition of
awaitproperly handles the now-asynchronousgetFormDatafunction call. This change aligns with the broader refactor to use asynchronous file handling utilities.Please verify that the
getFormDatafunction in the utils module has indeed been converted to asynchronous:
🏁 Script executed:
#!/bin/bash # Description: Verify that getFormData function is async in zoho_desk utils ast-grep --pattern $'async function getFormData($$$) { $$$ }' # Also check for async arrow function pattern ast-grep --pattern $'const getFormData = async ($$$) => { $$$ }' # Check the function signature in the utils file rg -A 5 "getFormData.*=" components/zoho_desk/common/utils.mjsLength of output: 2825
Confirmed:
getFormDatais async;awaitusage is correct.
- Verified in components/zoho_desk/common/utils.mjs (lines 33–42) that
getFormDatais declared as anasync function.- The change in components/zoho_desk/zoho_desk.app.mjs (line 137) now correctly awaits the async call.
components/pdf4me/actions/convert-to-pdf/convert-to-pdf.mjs (2)
8-8: Appropriate version bump for the refactor.The version increment from "0.0.1" to "0.1.0" correctly reflects the significant changes in file handling approach.
27-27:✅ Verification successful
Good modernization of file handling.
The change from synchronous filesystem operations to asynchronous
utils.getBase64Fileimproves the code by:
- Supporting both file URLs and
/tmppaths- Using platform utilities instead of direct
fsoperations- Maintaining proper async/await patterns
Please verify that the
getBase64Fileutility function exists and handles both URL and file path inputs correctly:
🏁 Script executed:
#!/bin/bash # Description: Verify getBase64File utility function exists and implementation ast-grep --pattern $'function getBase64File($$$) { $$$ }' # Also check for arrow function ast-grep --pattern $'const getBase64File = ($$$) => { $$$ }' # Check the implementation in utils file rg -A 10 "getBase64File" components/pdf4me/common/utils.mjsLength of output: 1004
Verified
getBase64FileUtilityThe
getBase64Fileasync function is present incomponents/pdf4me/common/utils.mjs(lines 40–47). It streams data viagetFileStream(filePath), collects all chunks, and returns a Base64-encoded string—covering both remote URLs and local/tmppaths. No further changes required.components/box/box.app.mjs (1)
16-17: Excellent improvement to user-facing documentation.The updated label and description clearly communicate that the input supports both file URLs and local
/tmppaths, with a helpful example. This aligns well with the underlying code changes to support dual input modes.components/pdf4me/actions/compress-pdf/compress-pdf.mjs (2)
8-8: Consistent version update across pdf4me actions.The version increment matches the pattern used in other pdf4me actions, maintaining consistency across the component.
43-43: Consistent modernization pattern applied.This change follows the same successful pattern as in the
convert-to-pdfaction, replacing synchronous filesystem operations with the asynchronousutils.getBase64Fileutility. The consistency across actions improves maintainability.components/askyourpdf/actions/add-document-via-file-upload/add-document-via-file-upload.mjs (2)
9-9: Appropriate version bump for enhanced functionality.The version update from "0.0.2" to "0.1.0" correctly reflects the addition of file URL support capability.
14-15: Consistent and clear property documentation.The updated label and description follow the same pattern established in other components (like Box), providing users with clear guidance on supported input types and a helpful example. This consistency improves the overall user experience across the platform.
components/pandadoc/pandadoc.app.mjs (1)
91-92: LGTM! Clear improvement to user guidance.The updated label and description effectively communicate that the property accepts both file URLs and local
/tmpfile paths, with a helpful example included.components/box/common/common-file-upload.mjs (1)
11-13:❓ Verification inconclusive
Excellent consolidation of file handling logic.
The refactor to use
utils.getFileData(file)simplifies the code by obtaining both file metadata and content in a single asynchronous call, replacing the previous multi-step process.Verify that the error handling previously provided by explicit validation is maintained within the
utils.getFileDatafunction:
🏁 Script executed:
#!/bin/bash # Description: Verify error handling in the utils.getFileData function # Search for the getFileData implementation ast-grep --pattern $'getFileData($_) { $$$ }' # Also search for error handling patterns rg -A 5 -B 5 "getFileData|ConfigurationError|throw.*Error" components/box/common/utils.mjsLength of output: 743
Verify error handling in utils.getFileData
The new
getFileData(filePath)implementation delegates directly togetFileStreamAndMetadataand no longer performs explicit validation or throwsConfigurationError. Please confirm that:
getFileStreamAndMetadata(filePath)reliably throws clear, descriptive errors for missing or invalid files.- Error semantics (e.g. mapping to
ConfigurationError) match the previous behavior, or add a validation/wrapping layer ingetFileDataif needed.• File: components/box/common/utils.mjs — review the
getFileDatamethod and its upstream error contracts.components/zamzar/zamzar.app.mjs (2)
11-12: LGTM! Consistent property definition improvement.The updated label and description align with the standardized approach across components to support both file URLs and
/tmpdirectory paths.
48-58: Proper async/await implementation for form data handling.The method is correctly updated to be async and properly awaits the
utils.getFormData(rawData)call, which aligns with the broader refactor to asynchronous file handling throughout the codebase.components/onlyoffice_docspace/actions/upload-file/upload-file.mjs (2)
8-8: Appropriate version increment for new functionality.The version bump from "0.0.1" to "0.1.0" correctly reflects the minor enhancement that adds file URL support alongside existing local file path functionality.
22-23: Consistent property definition improvement.The updated label and description maintain consistency with the standardized approach across components, clearly communicating support for both file URLs and
/tmpdirectory paths.components/slack/slack.app.mjs (1)
359-360: LGTM! Consistent improvement to user guidance.The updated label and description follow the standardized pattern across components, clearly communicating support for both file URLs and
/tmpdirectory paths with a helpful example.components/pdf4me/actions/merge-pdfs/merge-pdfs.mjs (2)
14-15: LGTM! Property descriptions are clear and consistent.The updated label and description properly clarify that both file URLs and
/tmpdirectory paths are supported, aligning with the broader file handling improvements.
8-8: Appropriate version bump for feature enhancement.The version increment from "0.0.1" to "0.1.0" correctly reflects the enhanced file handling capabilities.
components/nyckel/common/common-image.mjs (3)
3-3: Good modernization of import.Replacing the Node.js
fsmodule with the platform'sgetFileStreamAndMetadatautility aligns with the broader refactor pattern and provides better abstraction.
15-24: Excellent async refactor with explicit metadata handling.The change from conditional URL/filesystem handling to consistent async processing with explicit metadata (content type, size, filename) is a significant improvement. This approach provides better consistency and proper metadata handling for both URLs and local files.
17-19:❓ Verification inconclusive
Verify error handling for getFileStreamAndMetadata.
While the refactor is good, ensure that
getFileStreamAndMetadataproperly handles both URL and file path scenarios and provides meaningful error messages for debugging.
🏁 Script executed:
#!/bin/bash # Search for error handling patterns in getFileStreamAndMetadata usage across the codebase rg -A 5 -B 2 "getFileStreamAndMetadata" --type jsLength of output: 6616
#!/bin/bash # Show implementation of getLocalFileStreamAndMetadata to verify its error handling rg -n -A20 "getLocalFileStreamAndMetadata" platform/dist/file-stream.js
Confirm comprehensive error handling in getFileStreamAndMetadata
Please ensure that both the local‐file and remote‐URL branches of
getFileStreamAndMetadatasurface clear, actionable errors and are covered by tests:
- Verify that remote fetch failures (network errors, non-2xx status codes) include the URL and HTTP status or underlying error in the thrown message.
- Verify that local file errors (e.g. file not found, permission denied) reject with a message that includes the problematic path.
- Add or update unit tests for a “local file does not exist” scenario so we don’t regress on missing‐file handling.
Areas to review:
platform/dist/file-stream.js→getRemoteFileStreamAndMetadataplatform/dist/file-stream.js→getLocalFileStreamAndMetadatacomponents/_2markdown/actions/html-file-to-markdown/html-file-to-markdown.mjs (3)
2-2: Consistent import addition for platform utility.Adding the
getFileStreamAndMetadataimport aligns with the broader refactor to standardize file handling across components.
23-30: Excellent modernization of file handling logic.The replacement of direct
fs.createReadStreamusage with the platform'sgetFileStreamAndMetadatautility is well-implemented. The explicit metadata handling (content type, size, filename) in the FormData append provides better consistency and support for both URLs and local file paths.
9-9: Appropriate version increment.The version bump from "0.0.1" to "0.1.0" correctly reflects the enhanced file handling capabilities.
components/pdf4me/pdf4me.app.mjs (1)
10-11: Clear and helpful property definition updates.The updated label and description effectively communicate that both file URLs and
/tmpdirectory paths are supported. The example path (/tmp/myFile.doc) is particularly helpful for users understanding the expected format.components/_2markdown/_2markdown.app.mjs (1)
9-10: Consistent and clear property definition improvement.The updated label and description align with the broader file handling improvements across the platform. The HTML-specific description and example path (
/tmp/myFile.html) provide clear guidance to users about supported input formats.components/askyourpdf/askyourpdf.app.mjs (2)
30-48: LGTM! Proper async conversion for form data handling.The conversion from synchronous to asynchronous form data processing is correctly implemented. The method signature changes and await calls are properly aligned.
52-52: Correctly awaiting the async getConfig call.The makeRequest method properly awaits the now-async getConfig method.
components/mistral_ai/actions/upload-file/upload-file.mjs (1)
15-16: Good improvement to support both URLs and local paths.The updated property label and description clearly communicate that both file URLs and
/tmppaths are supported, improving flexibility for users.components/ocrspace/ocrspace.app.mjs (1)
14-15: Consistent property updates for unified file handling.The label and description changes align with the platform-wide improvement to support both file URLs and local paths, maintaining consistency across components.
components/_2markdown/actions/pdf-to-markdown/pdf-to-markdown.mjs (1)
30-37: Well-implemented migration to platform file utilities.The replacement of
fs.createReadStreamwithgetFileStreamAndMetadatais correctly implemented, with proper use of metadata for content type, size, and filename in the form data.components/slack/actions/upload-file/upload-file.mjs (1)
59-64: Excellent use of metadata for form data construction.The updated form data construction properly utilizes the metadata from
getFileStreamAndMetadata, including content type, size, and filename. This provides better file handling for both URLs and local files.components/stannp/common/utils.mjs (1)
22-34: Well-designed utility wrapper for file handling.The
getFileDatafunction provides a clean abstraction overgetFileStreamAndMetadatawith a standardized metadata structure. The field mapping tocontentType,knownLength, andfilenamealigns well with form-data requirements.components/zamzar/common/utils.mjs (1)
5-22:✅ Verification successful
Verify all callers handle the async buildFormData change.
The conversion from synchronous to asynchronous execution is well-implemented, with the proper change from
forEachtofor...ofloop to supportawait. However, this is a breaking change that requires all callers to be updated.Please verify that all callers of
getFormDatahave been updated to handle the async change:
🏁 Script executed:
#!/bin/bash # Search for usage of getFormData to ensure async handling rg -A 3 -B 3 "getFormData\(" --type js --type mjsLength of output: 79
🏁 Script executed:
#!/bin/bash # Retry searching for getFormData and buildFormData across JS/MJS files without relying on rg’s file-type filters rg "getFormData\(" -A 3 -B 3 -g "*.js" -g "*.mjs" rg "buildFormData\(" -A 3 -B 3 -g "*.js" -g "*.mjs"Length of output: 22042
All
getFormDataCallers Properly Handle the Async ConversionVerified in the Zamzar module that the only use of
utils.getFormDatais in
components/zamzar/zamzar.app.mjsand it’s correctly preceded byawait. No un-awaited calls to the now-asyncgetFormDataremain in the Zamzar code.components/monday/actions/update-column-values/update-column-values.mjs (2)
62-87: Excellent modernization of file upload logic.The
uploadFilemethod has been properly updated to usegetFileStreamAndMetadata, which provides better support for both file URLs and local paths. The metadata is correctly applied to the form data with proper content type, size, and filename information.
54-54: Good documentation update for file input flexibility.The description update clearly communicates that the file input now supports both URLs and local
/tmppaths, which improves user experience and aligns with the new functionality.components/onlyoffice_docspace/common/utils.mjs (1)
5-33:✅ Verification successful
Consistent async conversion pattern - verify caller updates.
This implementation follows the same excellent pattern as the zamzar utils file, properly converting from synchronous to asynchronous operations. The
for...ofloop correctly supportsawaitoperations, and the metadata handling is appropriate.Similar to the zamzar utils, please verify that all callers of
getFormDatain the onlyoffice_docspace component have been updated to handle the async change:
🏁 Script executed:
#!/bin/bash # Search for usage of getFormData in onlyoffice_docspace components rg -A 3 -B 3 "getFormData\(" components/onlyoffice_docspace/Length of output: 1242
Async getFormData usage verified—no action needed.
The only caller in components/onlyoffice_docspace/onlyoffice_docspace.app.mjs
now correctly awaitsutils.getFormData(preData), so the async conversion poses no breaking changes.components/mapbox/actions/create-tileset/create-tileset.mjs (3)
2-2: LGTM! Good refactor to use platform SDK.The migration from fs module to the platform SDK's
getFileStreamAndMetadatautility is a good improvement for consistency.
25-26: Good clarity improvement for the prop description.The updated label and description clearly indicate that both file URLs and local paths are supported.
54-61: Excellent async file handling implementation.The refactored code properly uses async/await and correctly applies the metadata (contentType, size, filename) to the FormData append operation.
components/zoho_desk/common/utils.mjs (3)
14-18: Correct async conversion for recursive form building.The conversion from
forEachtofor...ofwith proper await on recursive calls ensures sequential processing of nested data structures.
20-27: Proper async file handling with metadata.The implementation correctly uses
getFileStreamAndMetadataand applies all metadata properties to the FormData append operation.
33-36: Async function conversion handled correctly.The
getFormDatafunction properly awaits the asyncbuildFormDatacall.components/nyckel/nyckel.app.mjs (1)
32-33: Clear and consistent prop documentation.The updated label and description align with the platform-wide pattern of accepting both file URLs and local paths.
components/onlyoffice_docspace/onlyoffice_docspace.app.mjs (2)
49-66: Correct async conversion for form data handling.The
getConfigmethod properly awaits the asyncgetFormDatacall, maintaining the conditional logic for multipart handling.
68-75: Proper async chain maintained.The
_makeRequestmethod correctly awaits the now-asyncgetConfigmethod.components/onlinecheckwriter/actions/mail-pdf-document/mail-pdf-document.mjs (1)
2-2: LGTM! File handling standardization looks good.The migration to
getFileStreamAndMetadatafrom the platform SDK is implemented correctly. The property label/description updates clearly indicate support for both file URLs and/tmppaths, and the stream metadata is properly included when appending to the form data.Also applies to: 9-9, 21-22, 170-177
components/akeneo/actions/create-a-new-product-media-file/create-a-new-product-media-file.mjs (1)
2-4: Consistent implementation of file handling improvements.The changes properly implement the standardized file handling using
getFileStreamAndMetadata. The property updates clearly communicate the dual support for file URLs and/tmppaths, maintaining consistency with other components in this PR.Also applies to: 10-10, 35-36, 58-65
components/fileforge/actions/generate-pdf/generate-pdf.mjs (1)
2-3: Well-implemented multi-file handling with proper async processing.The changes correctly handle multiple files by awaiting
getFileStreamAndMetadatafor each file in the loop. The metadata (content type, size, filename) is properly attached to each file stream when appending to the form data.Also applies to: 10-10, 27-28, 66-73
components/pandadoc/actions/create-document-from-file/create-document-from-file.mjs (1)
10-10: Appropriate major version bump for breaking change.The removal of the
fileUrlproperty and related conditional logic is correctly reflected in the major version bump (0.0.8 → 1.0.0). The simplified implementation now consistently uses the standardized file handling approach viagetFormData.Also applies to: 61-75
components/askyourpdf/common/utils.mjs (1)
1-1: Excellent conversion to async file handling.The migration from synchronous
fs.createReadStreamto asynchronousgetFileStreamAndMetadatais properly implemented. The change fromforEachtofor...ofloop ensures correct sequential processing of async operations, which is crucial for maintaining the order of form data construction.Also applies to: 5-9, 11-18, 24-27
components/zoho_desk/actions/add-ticket-attachment/add-ticket-attachment.mjs (3)
9-9: Appropriate version bump for new functionality.The minor version increase correctly reflects the enhanced capability to accept both file URLs and local file paths.
35-36: Clear improvement to property documentation.The updated label and description effectively communicate that the action now supports both file URLs and local
/tmpfile paths, improving user experience.
47-57:✅ Verification successful
Verify that underlying file handling has been modernized.
While the property documentation has been updated to support file URLs and
/tmppaths, ensure that thezohoDesk.createTicketAttachmentmethod and related utilities have been updated to usegetFileStreamAndMetadatafrom@pipedream/platformto properly handle both URL and local file inputs.
🏁 Script executed:
#!/bin/bash # Description: Check if Zoho Desk utilities have been updated to use getFileStreamAndMetadata # Expected: Find usage of getFileStreamAndMetadata in Zoho Desk utilities echo "Checking for getFileStreamAndMetadata usage in Zoho Desk components:" rg -A 5 "getFileStreamAndMetadata" components/zoho_desk/ echo -e "\nChecking for createTicketAttachment implementation:" ast-grep --pattern 'createTicketAttachment($_) { $$$ }' echo -e "\nChecking for file handling in Zoho Desk utils:" rg -A 10 "buildFormData|getFormData" components/zoho_desk/Length of output: 4451
File handling modernized with getFileStreamAndMetadata
Confirmed that:
components/zoho_desk/common/utils.mjs’sbuildFormDatanow imports and usesgetFileStreamAndMetadatafor any file property.components/zoho_desk/zoho_desk.app.mjs’screateTicketAttachmentmethod appliesutils.getFormData(...)when the multipart header is present, ensuring URLs and local paths are handled correctly.No further action required.
components/box/common/utils.mjs (3)
3-3: Excellent modernization by adopting platform utilities.The import of
getFileStreamAndMetadataaligns with the platform-wide effort to standardize file handling.
6-26: Well-implemented async file handling refactor.The refactored
getFileDatamethod properly:
- Uses async/await pattern
- Leverages the platform's
getFileStreamAndMetadatautility- Returns a consistent structure with both stream and metadata
- Maps metadata fields appropriately for Box API requirements
The transformation of
metadata.lastModifiedto ISO format and the use ofpath.basename(filePath)for the filename are correct implementations.
19-21:✅ Verification successful
Verify that hardcoded parent ID is appropriate.
The parent ID is hardcoded to
0. Ensure this is the correct default value for Box API uploads or if it should be configurable.
🏁 Script executed:
#!/bin/bash # Description: Check Box API documentation or existing usage patterns for parent ID # Expected: Find documentation or examples of parent ID usage in Box uploads echo "Checking for parent ID usage patterns in Box components:" rg -A 3 -B 3 "parent.*id" components/box/ echo -e "\nChecking for Box upload examples:" rg -A 10 "upload.*file|create.*file" components/box/Length of output: 7057
Confirmed default
parent.id = 0is correct
Box API uses0to denote the root folder (seecomponents/box/box.app.mjsdefault:"0"), and theparentIdprop remains configurable—common-file-upload.mjswill override it when provided. No changes required.components/stannp/actions/create-campaign/create-campaign.mjs (5)
5-5: Correct import update for modernized file handling.The change from
checkFiletogetFileDataaligns with the platform-wide refactoring to use async file utilities.
12-12: Appropriate version bump for enhanced functionality.The minor version increase correctly reflects the new capability to handle both file URLs and local paths.
61-62: Excellent property documentation improvements.The updated labels and descriptions clearly communicate support for both file URLs and
/tmpfile paths, providing helpful examples for users.Also applies to: 68-69, 75-76
110-127: Well-implemented async file handling with proper metadata.The refactored file handling logic correctly:
- Uses async/await pattern for
getFileDatacalls- Destructures stream and metadata from the response
- Appends files to FormData with metadata for proper multipart uploads
This implementation follows best practices for handling file streams in multipart forms.
5-5:✅ Verification successful
Verify that getFileData utility is properly implemented.
Ensure that the
getFileDatafunction in../../common/utils.mjshas been updated to usegetFileStreamAndMetadataand returns the expected{ stream, metadata }structure.
🏁 Script executed:
#!/bin/bash # Description: Verify getFileData implementation in Stannp utils # Expected: Find getFileData function using getFileStreamAndMetadata echo "Checking getFileData implementation in Stannp utils:" cat components/stannp/common/utils.mjs echo -e "\nChecking for getFileStreamAndMetadata usage:" rg "getFileStreamAndMetadata" components/stannp/Length of output: 1194
getFileData implementation is correct
The
getFileDatafunction incomponents/stannp/common/utils.mjsalready importsgetFileStreamAndMetadataand returns the expected{ stream, metadata }shape:export const getFileData = async (file) => { const { stream, metadata } = await getFileStreamAndMetadata(file); return { stream, metadata: { contentType: metadata.contentType, knownLength: metadata.size, filename: metadata.name, }, }; };No further changes required.
components/pandadoc/actions/create-document-attachment/create-document-attachment.mjs (5)
2-2: Excellent adoption of platform utilities.The import of
getFileStreamAndMetadataaligns with the platform-wide standardization effort.
10-10: Appropriate version bump for modernization.The minor version increase correctly reflects the internal improvements to file handling.
32-44: Excellent async refactor with proper metadata handling.The refactored
getFormDatamethod demonstrates best practices:
- Properly async with await for
getFileStreamAndMetadata- Destructures stream and metadata correctly
- Uses provided
fileNamewith fallback tometadata.name- Includes comprehensive metadata in FormData append (contentType, knownLength, filename)
This implementation ensures proper multipart form handling for document attachments.
53-53: Correct async handling in run method.The
awaitfor the asyncgetFormDatacall is properly implemented.
19-24:✅ Verification successful
Verify that file property definition supports URLs and paths.
Ensure that the
fileprop definition in the PandaDoc app has been updated to clarify support for both file URLs and/tmpfile paths, consistent with the other components in this PR.
🏁 Script executed:
#!/bin/bash # Description: Check if PandaDoc file property definition has been updated # Expected: Find file prop definition with updated label/description echo "Checking PandaDoc app file property definition:" rg -A 5 -B 2 'file.*propDefinition|propDefinition.*file' components/pandadoc/ echo -e "\nChecking for file-related props in PandaDoc:" rg -A 10 '"file"' components/pandadoc/pandadoc.app.mjsLength of output: 346
🏁 Script executed:
#!/bin/bash # Verify propDefinition and file entries in the create-document-attachment action echo "Searching for propDefinition in create-document-attachment.mjs:" rg -n -C 3 "propDefinition" components/pandadoc/actions/create-document-attachment/create-document-attachment.mjs || true echo -e "\nSearching for 'file:' blocks in create-document-attachment.mjs:" rg -n -C 3 "file:" components/pandadoc/actions/create-document-attachment/create-document-attachment.mjs || trueLength of output: 854
🏁 Script executed:
#!/bin/bash # Search for the propDefinitions block in the PandaDoc app file echo "Locating propDefinitions in pandadoc.app.mjs:" rg -n -C 3 "propDefinitions" components/pandadoc/pandadoc.app.mjs || true echo -e "\nExtracting the 'file' entry under propDefinitions:" rg -n -C 5 "file *:" components/pandadoc/pandadoc.app.mjs || trueLength of output: 849
✅ File propDefinition supports both URLs and
/tmppathsThe
fileprop increate-document-attachment.mjscorrectly inherits its definition from the centralpropDefinitions.fileinpandadoc.app.mjs, which now specifies:
- Label: “File Path or URL”
- Description: “The file to upload. Provide either a file URL or a path to a file in the
/tmpdirectory (for example,/tmp/myFile.txt)”Locations verified:
components/pandadoc/pandadoc.app.mjs–propDefinitions.fileincludes the updated label and description.components/pandadoc/actions/create-document-attachment/create-document-attachment.mjs–file: { propDefinition: [app, "file"] }correctly references this definition.No further changes needed.
vunguyenhung
moved this from Ready for PR Review
to Ready for QA
in Component (Source and Action) Backlog
vunguyenhung
moved this from Ready for QA
to Changes Required
in Component (Source and Action) Backlog
|
Hello everyone, I have tested this PR and there're some test cases failed or needed improvement. Please check the test report below for more information |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
components/zoho_desk/actions/add-ticket-attachment/add-ticket-attachment.mjs (1)
36-38: Property description still constrains uploads to/tmp
getFileStreamAndMetadataalso supports arbitrary HTTP/HTTPS URLs. Consider relaxing the wording so users aren’t mis-led into thinking remote URLs must first be copied to/tmp.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
components/zoho_desk/actions/add-ticket-attachment/add-ticket-attachment.mjs(3 hunks)components/zoho_desk/zoho_desk.app.mjs(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Lint Code Base
- GitHub Check: Publish TypeScript components
- GitHub Check: pnpm publish
- GitHub Check: Verify TypeScript components
🔇 Additional comments (2)
components/zoho_desk/actions/add-ticket-attachment/add-ticket-attachment.mjs (2)
2-3: Missing dependency declaration forform-data
form-datais imported directly, but the package isn’t guaranteed to exist in every component bundle.
Please ensure it is listed underpackage.json→dependenciesfor the Zoho Desk component package.
71-71: Response object shape – verify correct field for summaryThe axios wrapper often returns
{ data: { id, … } }. Usingresponse?.idmay yieldundefined.
Consider:-$.export("$summary", `Successfully created a new ticket attachment with ID ${response?.id}`); +$.export("$summary", `Successfully created a new ticket attachment with ID ${response?.data?.id ?? response?.id}`);
components/zoho_desk/actions/add-ticket-attachment/add-ticket-attachment.mjs
Show resolved
Hide resolved
components/zoho_desk/actions/add-ticket-attachment/add-ticket-attachment.mjs
Show resolved
Hide resolved
|
Fixed the following components:
The following components have other issues:
We should investigate these remaining components in new bugfix tickets. |
GTFalcao
moved this from Changes Required
to Ready for QA
in Component (Source and Action) Backlog
|
Closing this: the changes here will be merged in #17091 instead (which already includes them) |
github-project-automation
bot
moved this from Ready for QA
to Done
in Component (Source and Action) Backlog
Partially addresses #16977
27 components updated
Note: we're intentionally only updating the versions of components that use file handling and are being directly updated, to avoid mass publishing of unrelated components.
Summary by CodeRabbit
Summary by CodeRabbit
New Features
/tmp/myFile.txt), enhancing flexibility in file sourcing.Improvements
Bug Fixes
Documentation
Chores