chore: support array content values in portkey plugin checks

[VisargD]

Description

Motivation

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)

How Has This Been Tested?

• Unit Tests
• Integration Tests
• Manual Testing

Screenshots (if applicable)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Related Issues

[matter-code-review]

Description

Summary By MatterAI

🔄 What Changed

This Pull Request introduces support for array content values within Portkey plugin checks. It achieves this by integrating a new utility function, getCurrentContentPart, to intelligently extract content from various request/response structures. Robust error handling has been added to gracefully manage scenarios where content might be empty or missing.

🔍 Impact of the Change

This change enhances the flexibility and reliability of Portkey plugins, allowing them to process a wider range of content formats, including array-based values. The added error handling for empty content improves the stability of the plugins by preventing potential failures when expected data is absent.

📁 Total Files Changed

3 files were changed:

• plugins/portkey/gibberish.ts
• plugins/portkey/language.ts
• plugins/portkey/moderateContent.ts

🧪 Test Added(explain each test in detail)

N/A

🔒Security Vulnerabilities

No security vulnerabilities were detected in this Pull Request.

Motivation

To enhance the Portkey plugins' ability to process diverse content structures, specifically array-based content, and to improve error handling for cases where content might be missing or empty.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)

How Has This Been Tested?

• Unit Tests
• Integration Tests
• Manual Testing

Screenshots (if applicable)

N/A

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Related Issues

.

Tip

Quality Recommendations

1. Consider using filter(Boolean) for conciseness when filtering out falsy values from an array.

2. If possible, make the error message for empty content more specific (e.g., 'request content is empty' vs. 'response content is empty') based on the getCurrentContentPart's ability to differentiate.

Sequence Diagram

sequenceDiagram
    participant PluginHandler
    participant getCurrentContentPart
    participant Portkey API

    PluginHandler->>getCurrentContentPart: Call with context, eventType
    getCurrentContentPart-->>PluginHandler: Returns { content, textArray }
    alt If content is empty
        PluginHandler-->>PluginHandler: Return early with error
    else If content is not empty
        PluginHandler->>PluginHandler: Filter and join textArray to 'text'
        PluginHandler->>Portkey API: Call fetchPortkey with 'text' and parameters
        Portkey API-->>PluginHandler: Returns API response
        PluginHandler->>PluginHandler: Process API response
    end

Loading

[matter-code-review]

This PR introduces valuable improvements by supporting array content values and adding robust error handling. I've identified a minor refactoring opportunity for conciseness.

[narengogi]

Approving, but I dont see you making use of contentParts in any of these plugins, we're essentially doing the same thing as getText() but now with an added step inside the plugin to concatenate text parts, are these changes for deprecating getText() in the future?

[VisargD]

@narengogi - getText function does not handle the new structure of messages where content can be an array of multiple parts.

The new function returns the final message content parts as well as just the array of text. Depending on the plugin check, we use content part or text array as both of them have their own use cases.

And yes, we need to deprecate getText soon