Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: nested file schema processor #1354

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

himanshu-dixit
Copy link
Collaborator

@himanshu-dixit himanshu-dixit commented Feb 21, 2025

Important

Introduces nested file schema processing in file.ts and fixes a typo in actions.spec.ts.

  • File Schema Processing:
    • Adds updateSingleProperty and updateAnyOfProperties functions in file.ts to handle nested file schemas.
    • Modifies FILE_SCHEMA_PROCESSOR to process anyOf properties and update schema properties accordingly.
  • Tests:
    • Fixes typo in actions.spec.ts by renaming connectedAccouns to connectedAccounts.

This description was created by Ellipsis for f751574. It will automatically update as commits are pushed.

Copy link

vercel bot commented Feb 21, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
composio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 24, 2025 8:13am

Comment on lines +129 to +133
return {
title: key,
type,
description: property.description,
};

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When handling anyOf properties, the new code uses property.description instead of schema.description, which could show incorrect descriptions for file upload fields

📝 Committable Code Suggestion

‼️ Ensure you review the code suggestion before committing it to the branch. Make sure it replaces the highlighted code, contains no missing lines, and has no issues with indentation.

Suggested change
return {
title: key,
type,
description: property.description,
};
return {
title: key,
type,
description: schema.description,
};

@@ -38,6 +38,12 @@
for (const [key, value] of Object.entries(result)) {
if (!key.endsWith(FILE_SUFFIX)) continue;

const isEmpty = value === "" || !value;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider extracting this empty value check into a reusable utility function to maintain consistency across the codebase:

const isEmptyValue = (value: unknown): boolean => value === "" || !value;

This would make the code more maintainable and allow for easier updates to empty value logic if needed.


const updateAnyOfProperties = (key: string, property: any) => {
let newKeyName = key;
const newAnyOf = property.anyOf.map((schema: any) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The property.anyOf array should be type-checked before mapping. Consider adding validation:

if (!Array.isArray(property.anyOf)) {
  throw new Error(`Invalid schema: ${key} anyOf property must be an array`);
}

This would prevent runtime errors if the schema is malformed.

for (const [key, property] of Object.entries(newProperties)) {
if (!property.file_uploadable) continue;

const updateSingleProperty = (key: string, property: any) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The property parameter is typed as any. Consider creating a proper type definition:

interface FileSchemaProperty {
  file_uploadable?: boolean;
  type: string;
  description?: string;
  [key: string]: unknown;
}

This would improve type safety and code maintainability.

Copy link

github-actions bot commented Feb 21, 2025

This comment was generated by github-actions[bot]!

JS SDK Coverage Report

📊 Coverage report for JS SDK can be found at the following URL:
https://pub-92e668239ab84bfd80ee07d61e9d2f40.r2.dev/coverage-13493511777/coverage/index.html

📁 Test report folder can be found at the following URL:
https://pub-92e668239ab84bfd80ee07d61e9d2f40.r2.dev/html-report-13493511777/html-report/report.html

Copy link
Contributor

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Looks good to me! Incremental review on f751574 in 39 seconds

More details
  • Looked at 28 lines of code in 1 files
  • Skipped 0 files when reviewing.
  • Skipped posting 5 drafted comments based on config settings.
1. js/src/sdk/models/actions.spec.ts:9
  • Draft comment:
    Fixed typo: variable 'connectedAccouns' renamed to 'connectedAccounts'.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
    This comment is purely informative, as it only states that a typo was fixed. It does not provide any actionable feedback or suggestions for improvement.
2. js/src/sdk/models/actions.spec.ts:9
  • Draft comment:
    Fixed typo in variable declaration: 'connectedAccouns' → 'connectedAccounts'.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
    This comment is purely informative, pointing out a typo that was fixed. It doesn't provide a suggestion or ask for confirmation about the change. According to the rules, purely informative comments should be removed.
3. js/src/sdk/models/actions.spec.ts:14
  • Draft comment:
    Corrected variable name typo during initialization: 'connectedAccouns' → 'connectedAccounts'.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
    This comment is purely informative as it only states that a typo was corrected. It does not provide any actionable feedback or suggestions for improvement.
4. js/src/sdk/models/actions.spec.ts:39
  • Draft comment:
    Fixed typo in method call: changed 'connectedAccouns.list' to 'connectedAccounts.list'.
  • Reason this comment was not posted:
    Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
    This comment is purely informative, as it only states that a typo was fixed in a method call. It does not provide any actionable feedback or suggestions for improvement.
5. js/src/sdk/models/actions.spec.ts:55
  • Draft comment:
    Typo: 'successfull' should be 'successful' to correctly spell the word.
  • Reason this comment was not posted:
    Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_AYpohDtlXJKTjuHz


You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

@shreysingla11
Copy link
Collaborator

Code Review Summary

Overall Assessment

The changes implement nested file schema processing with good separation of concerns and proper handling of edge cases. The code is generally well-structured but could benefit from some improvements in type safety and error handling.

Strengths

✅ Clean separation of concerns between single and nested property handling
✅ Proper cleanup of processed properties
✅ Good handling of empty field cases
✅ Maintains schema validation requirements

Areas for Improvement

  1. Type Safety

    • Several instances of any type usage could be replaced with proper interfaces
    • Array type checking could be strengthened
  2. Error Handling

    • Add validation for schema structure
    • Consider adding error messages for invalid configurations
  3. Code Organization

    • Extract common utilities (like empty value checking)
    • Add JSDoc documentation for new functions

Rating: 7/10

Good implementation with room for improvement in type safety and error handling.

The changes are safe to merge after addressing the suggested improvements in the review comments.

Copy link
Contributor

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❌ Changes requested. Reviewed everything up to bcbfd1b in 2 minutes and 46 seconds

More details
  • Looked at 73 lines of code in 1 files
  • Skipped 0 files when reviewing.
  • Skipped posting 5 drafted comments based on config settings.
1. js/src/sdk/utils/processor/file.ts:41
  • Draft comment:
    Using '!value' may remove valid falsy values. Given that file uploads expect a non-empty string, ensure that this check doesn't inadvertently remove valid inputs (e.g., '0').
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
    Since this is specifically for file uploads (checked by FILE_SUFFIX), the only valid values would be file data or file paths as strings. The value '0' or other falsy values would never be valid file upload data. The code is correctly checking for empty strings and null/undefined values. The comment's concern about falsy values is not relevant in this context.
    I could be wrong about what constitutes valid file data - there might be edge cases I'm not considering. The code might handle file-like objects that could have different falsy representations.
    Looking at the usage in getFileDataAfterUploadingToS3(), the value is explicitly cast to string and used as file data. No other types would make sense here.
    The comment should be deleted as it raises concerns about falsy values that aren't relevant in a file upload context where only string data is valid.
2. js/src/sdk/utils/processor/file.ts:117
  • Draft comment:
    In updateAnyOfProperties, newKeyName is reassigned within the map for each file_uploadable schema. If multiple anyOf items are file_uploadable, the final key may be unexpected. Confirm if this behavior is intended.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
    The comment raises a valid point - if multiple schemas in anyOf are file_uploadable, the final newKeyName will be from the last file_uploadable schema processed. However, looking at convertFileSchemaProperty(), it always generates the same keyName for a given key (key + FILE_SUFFIX), so multiple file_uploadable schemas would generate the same keyName anyway. This makes the concern moot.
    I could be wrong about the intended behavior - maybe there's a case where different file_uploadable schemas should generate different suffixes that I'm not seeing.
    The code clearly shows that convertFileSchemaProperty() uses a constant FILE_SUFFIX, so there's no way for different file_uploadable schemas to generate different keyNames for the same base key.
    The comment should be deleted because the behavior is actually correct - all file_uploadable schemas for a given key should generate the same keyName.
3. js/src/sdk/utils/processor/file.ts:41
  • Draft comment:
    Using '!value' in the emptiness check may remove valid non-string falsey values. Confirm that only empty strings are expected.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
    Since this is file processing code and the value is used as a string for file upload (line 49: value as string), other falsey values like 0 or false would not be valid file data anyway. The check is specifically looking for empty/missing file data before attempting upload. The current check is appropriate for this use case.
    I could be wrong about the requirements - maybe there are valid file upload scenarios where falsey values should be preserved.
    Given this is clearly file upload processing code and the value must be a string for S3 upload, preserving non-string falsey values would not make sense in this context.
    The comment should be removed as it raises a theoretical issue that is not applicable in this specific file upload context where the value must be a string.
4. js/src/sdk/utils/processor/file.ts:127
  • Draft comment:
    The variable 'newKeyName' is overwritten for each file_uploadable schema in anyOf. Ensure that if multiple schemas qualify, the intended key is applied.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
    The code does reassign newKeyName for each file_uploadable schema, but this actually appears intentional. The keyName returned by convertFileSchemaProperty will always be the same for a given key (it just appends FILE_SUFFIX). So even with multiple file_uploadable schemas, the final newKeyName would be consistent. The map is transforming the schemas while preserving the overall anyOf structure.
    I could be wrong about the intention - maybe there's a case where different schemas should produce different key names. The code could be more explicit about this pattern.
    The consistent key name transformation (just appending FILE_SUFFIX) means this isn't actually a bug - it's working as designed to handle file uploads within anyOf schemas.
    The comment raises a theoretical concern but doesn't identify an actual bug, since the key name transformation is consistent by design.
5. js/src/sdk/utils/processor/file.ts:147
  • Draft comment:
    Modifying newProperties while iterating over Object.entries returns a snapshot, but this pattern could be confusing. Consider documenting or refactoring for clarity.
  • Reason this comment was not posted:
    Confidence changes required: 33% <= threshold 50%
    None

Workflow ID: wflow_2PRjv3z0drSH6LZw


Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

return {
title: key,
type,
description: property.description,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In updateAnyOfProperties, the conversion returns a 'description' but the returned object uses property.description instead. Consider using the converted description for consistency.

Suggested change
description: property.description,
description: description,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants