[ACTION] Break Runware action into individual actions #14600
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
|
@jcortes is attempting to deploy a commit to the Pipedreamers Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughThis pull request introduces multiple new modules for distinct actions within the Runware API, including image background removal, captioning, preprocessing, inference, upscaling, and prompt enhancement. Each module defines its own set of properties and an asynchronous Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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: 15
🧹 Outside diff range and nitpick comments (15)
components/runware/actions/image-caption/image-caption.mjs (1)
5-11: Consider making the documentation URL configurable.While the metadata is well-structured, having the documentation URL hardcoded in the description could lead to maintenance issues if the documentation structure changes.
Consider moving the URL to a constants file or configuration:
+const DOCS_URL = "https://docs.runware.ai/en/utilities/image-to-text"; + export default { key: "runware-image-caption", name: "Image Caption", - description: "Request an image caption task to be processed by the Runware API. [See the documentation](https://docs.runware.ai/en/utilities/image-to-text).", + description: `Request an image caption task to be processed by the Runware API. [See the documentation](${DOCS_URL}).`, version: "0.0.1", type: "action",components/runware/common/constants.mjs (2)
31-56: LGTM! Consider adding documentation for technical terms.The structure is well-organized and consistent with existing patterns. However, some technical terms like "LoRA" and "Control Net" might benefit from documentation to improve maintainability.
Consider adding JSDoc comments to explain these specialized terms:
+/** + * Defines the structure for different types of image inference operations. + * @constant + * @type {Object} + * @property {Object} TEXT_TO_IMAGE - Generate images from text descriptions + * @property {Object} IMAGE_TO_IMAGE - Transform existing images + * @property {Object} IN_OUT_PAINTING - Modify specific areas of images + * @property {Object} REFINER - Enhance image quality + * @property {Object} CONTROL_NET - Advanced control over image generation + * @property {Object} LORA - Low-Rank Adaptation for fine-tuning + */ const IMAGE_INFERENCE_STRUCTURE = {
31-56: Consider using uppercase for constant values.For consistency with JavaScript conventions, consider using uppercase for the constant values.
const IMAGE_INFERENCE_STRUCTURE = { TEXT_TO_IMAGE: { - value: "textToImage", + value: "TEXT_TO_IMAGE", label: "Text to Image", }, IMAGE_TO_IMAGE: { - value: "imageToImage", + value: "IMAGE_TO_IMAGE", label: "Image to Image", }, // ... similar changes for other values };components/runware/actions/prompt-enhance/prompt-enhance.mjs (2)
5-10: Consider starting with version 1.0.0.The action metadata is well-defined with clear description and documentation link. However, since this is a new production-ready action (part of breaking down the main action), consider starting with version 1.0.0 instead of 0.0.1 to indicate its stable status.
- version: "0.0.1", + version: "1.0.0",
13-17: Add length validation for the prompt property.While the enhanced prompt has length constraints, the input prompt should also have reasonable length limits to prevent potential issues with extremely short or long inputs.
prompt: { type: "string", label: "Prompt", description: "The prompt that you intend to enhance.", + minLength: 3, + maxLength: 1000, },components/runware/actions/image-upscale/image-upscale.mjs (2)
11-44: Consider marking required properties and adding validation.While the props are well-defined, consider the following improvements:
- Mark required properties explicitly (e.g., inputImage should likely be required)
- Add input validation for the upscaleFactor to ensure optimal processing
inputImage: { propDefinition: [ app, "inputImage", ], + required: true, }, upscaleFactor: { type: "integer", label: "Upscale Factor", description: "The level of upscaling performed. Each will increase the size of the image by the corresponding factor. Eg. `2`.", min: 2, max: 4, + required: true, + default: 2, },
1-73: Well-structured module that aligns with PR objectives.This module successfully implements a dedicated image upscale action, contributing to the goal of breaking down the monolithic Runware action. The implementation:
- Focuses on a single responsibility
- Provides specific fields for upscaling
- Follows a consistent pattern that can be replicated
Consider documenting the common patterns and requirements for other action implementations to maintain consistency across the codebase.
components/runware/runware.app.mjs (1)
Line range hint
1-99: Consider adding validation for theinputImageproperty.While the property description clearly specifies the accepted formats, consider adding runtime validation to ensure the input matches one of the expected formats (UUID v4, data URI, base64, or URL).
Example validation helper:
methods: { validateInputImage(value) { // UUID v4 format const uuidV4Regex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i; // Data URI format const dataUriRegex = /^data:image\/(png|jpg|jpeg|webp);base64,/i; // URL format const urlRegex = /^https?:\/\/.+/i; return ( uuidV4Regex.test(value) || dataUriRegex.test(value) || urlRegex.test(value) || // Base64 check (simplified) /^[A-Za-z0-9+/=]+$/.test(value) ); } }components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs (4)
90-91: Remove unnecessary destructuring ofappin therunmethodThe
appmodule is already imported at the top level and doesn't need to be destructured fromthis. Removingappfrom the destructured variables in therunmethod enhances code clarity.Apply this diff to clean up the code:
async run({ $ }) { const { - app, outputType, outputFormat, includeCost,
70-80: Add conditional validation for Canny thresholdsThe properties
lowThresholdCannyandhighThresholdCannyare specific to the "canny" preprocessor. Add validation to ensure these properties are only used whenpreProcessorTypeis set to "canny", preventing irrelevant parameters from being sent in the request.
82-86: Add conditional validation for OpenPose propertyThe
includeHandsAndFaceOpenPoseproperty is applicable only when using the "openpose" preprocessor. Implement validation to ensure this property is only considered whenpreProcessorTypeis "openpose", enhancing the accuracy of the API requests.
103-125: Implement error handling for the API requestCurrently, if the
app.postrequest fails, the function will throw an unhandled exception. Implementing error handling will allow the action to fail gracefully and provide meaningful error messages.Apply this diff to add error handling:
+ try { const response = await app.post({ $, data: [ { taskType: constants.TASK_TYPE.IMAGE_CONTROL_NET_PREPROCESS.value, taskUUID: uuid(), outputType, outputFormat, inputImage, includeCost, height, width, preProcessorType, lowThresholdCanny, highThresholdCanny, includeHandsAndFaceOpenPose, }, ], }); $.export("$summary", `Successfully requested image control net preprocess task with UUID \`${response.data[0].taskUUID}\`.`); return response; + } catch (error) { + $.export("$summary", `Failed to request image control net preprocess task: ${error.message}`); + throw error; + }components/runware/actions/image-inference/image-inference.mjs (3)
115-117: Specify 'min' and 'max' for 'ControlNet Weight 0'The
controlNetWeightproperty likely expects values within a specific range. Definingminandmaxvalues ensures proper input validation and prevents out-of-range errors.Apply this diff to define constraints:
type: "integer", label: "ControlNet Weight 0", description: "The weight for ControlNet.", + min: 0, + max: 1, optional: true,
144-148: Specify 'min' and 'max' for 'LoRA Weight 0'The
loraWeightproperty should have constraints to ensure the sum of weights equals1. Addingminandmaxvalues aids in input validation.Apply this diff to define constraints:
type: "integer", label: "LoRA Weight 0", description: "...", + min: 0, + max: 1, optional: true,
189-193: Specify 'min' and 'max' for 'CFGScale'The
CFGScaleproperty mentionsMin: 0,Max: 30, andDefault: 7in the description but lacks these constraints in the definition. Addingminandmaxensures users provide valid input within the expected range.Apply this diff to include constraints:
type: "number", label: "CFG Scale", description: "...", + min: 0, + max: 30, optional: true,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
components/runware/actions/image-background-removal/image-background-removal.mjs(1 hunks)components/runware/actions/image-caption/image-caption.mjs(1 hunks)components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs(1 hunks)components/runware/actions/image-inference/image-inference.mjs(1 hunks)components/runware/actions/image-upscale/image-upscale.mjs(1 hunks)components/runware/actions/prompt-enhance/prompt-enhance.mjs(1 hunks)components/runware/actions/request-task/request-task.mjs(0 hunks)components/runware/common/constants.mjs(1 hunks)components/runware/package.json(1 hunks)components/runware/runware.app.mjs(1 hunks)
💤 Files with no reviewable changes (1)
- components/runware/actions/request-task/request-task.mjs
✅ Files skipped from review due to trivial changes (1)
- components/runware/package.json
🔇 Additional comments (13)
components/runware/actions/image-caption/image-caption.mjs (2)
1-3: LGTM! Dependencies are properly imported.
The imports are well-structured and necessary for the module's functionality. Using UUID v4 is appropriate for generating unique task identifiers.
11-25: 🛠️ Refactor suggestion
Add input validation for image properties.
While the props are well-defined, consider adding validation for the inputImage to ensure it meets the API's requirements (format, size, etc.) before making the API call.
Let's check if there are any image validation implementations in other files:
Consider adding validation in the run method:
async run({ $ }) {
const { app, inputImage, includeCost } = this;
// Add validation
if (!inputImage) {
throw new Error("Input image is required");
}
// Add format/size validation based on API requirements
const response = await app.post({
// ... rest of the code
});
}components/runware/common/constants.mjs (2)
58-63: LGTM! Export modification is clean and well-organized.
The new constant is properly exported and maintains alphabetical ordering.
31-56: Verify the usage of new inference structure values.
Let's ensure consistent usage of the new structure across the codebase and check for any lingering references to old formats.
✅ Verification successful
The new inference structure values are properly integrated and used consistently
The verification shows that:
- The
IMAGE_INFERENCE_STRUCTUREconstant is only imported and used within the image-inference action component - All structure values (
textToImage,imageToImage,inOutpainting,refiner,controlNet,lora) are used consistently in conditional logic to determine the appropriate parameters for each inference type - No old task references or inconsistent usage patterns were found
- The implementation properly handles all the defined structure types with their corresponding parameters
The changes appear to be well-integrated and maintain consistency throughout the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the usage of IMAGE_INFERENCE_STRUCTURE values and check for potential inconsistencies
# Test 1: Find all references to the inference types to ensure consistent usage
echo "Checking usage of inference type values..."
rg -i "textToImage|imageToImage|inOutpainting|refiner|controlNet|lora" \
--type js --type mjs
# Test 2: Look for potential old task type references that might need updating
echo "Checking for potential old task references..."
rg -i "requestTask|request-task" \
--type js --type mjs
Length of output: 401
Script:
#!/bin/bash
# Let's modify our search to handle .mjs files correctly and add more context
# Search for inference type values
echo "=== Searching for inference type values ==="
rg -i "textToImage|imageToImage|inOutpainting|refiner|controlNet|lora" \
--type-add 'js:*.{js,mjs,jsx}' \
--type js -C 2
# Search for potential imports or uses of the constants
echo -e "\n=== Searching for imports and uses of IMAGE_INFERENCE_STRUCTURE ==="
rg "IMAGE_INFERENCE_STRUCTURE" \
--type-add 'js:*.{js,mjs,jsx}' \
--type js -C 2
# Search for potential old task references
echo -e "\n=== Searching for old task references ==="
rg -i "requestTask|request-task" \
--type-add 'js:*.{js,mjs,jsx}' \
--type js
Length of output: 33313
components/runware/actions/prompt-enhance/prompt-enhance.mjs (2)
1-3: LGTM: Imports are well-structured and necessary.
The imports are appropriate for the module's functionality, using named imports where applicable.
48-60: Verify API endpoint compatibility.
Since this is a new action, we should verify that the Runware API endpoint accepts all the parameters we're sending, especially the new task type PROMPT_ENHANCE.
components/runware/actions/image-upscale/image-upscale.mjs (2)
1-3: LGTM: Imports are appropriate and necessary.
The imports are well-organized and each serves a clear purpose in the module.
5-11: Verify the documentation link.
The documentation link looks good, but please verify that it resolves to the correct page and the content is up-to-date.
✅ Verification successful
Documentation link is valid and accessible
The documentation link https://docs.runware.ai/en/image-editing/upscaling returns a successful HTTP 200 response, confirming it's accessible and properly configured.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the documentation link is valid
# Expected: The URL should return a 200 status code
curl -s -I "https://docs.runware.ai/en/image-editing/upscaling" | head -n 1
Length of output: 87
components/runware/runware.app.mjs (2)
56-60: Well-structured implementation of the inputImage property.
The property definition is comprehensive and well-documented, with clear specifications for:
- Multiple input formats (UUID, data URI, base64, URL)
- Supported image formats
- Links to relevant documentation
Line range hint 1-99: Verify the removal of task-specific properties.
The removal of properties like uploadEndpoint, checkNSFW, positivePrompt, etc., aligns with breaking down the Runware action into individual actions. However, we should verify that these properties are properly relocated to their respective new action modules.
✅ Verification successful
Properties have been properly relocated to task-specific modules
The verification confirms that the removed properties from the app-level configuration have been correctly relocated to their respective task-specific modules. Specifically:
- The
image-inferenceaction module now contains all the relevant properties includingpositivePrompt,negativePrompt,model,steps,scheduler,seed,strength,maskImage,seedImage, andcheckNSFW. - The properties are properly organized based on the task structure (Text-to-Image, Image-to-Image, In/Out-Painting, etc.) through the
additionalProps()method. - Each property maintains its proper type definitions, descriptions, and validation rules.
The architectural change improves modularity by moving task-specific properties to their respective action modules while keeping common properties at the app level.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that removed properties are defined in new task-specific modules
# Expected: Find these properties in new action-specific files
echo "Searching for removed properties in new action modules..."
for prop in "uploadEndpoint" "checkNSFW" "positivePrompt" "negativePrompt" "seedImage" "maskImage" "strength" "model" "steps" "scheduler" "seed"; do
echo "Checking property: $prop"
rg -l "\"$prop\".*{" components/runware/actions/
done
Length of output: 4078
Script:
#!/bin/bash
# Let's try a different approach to find the properties in action files
# First, let's see what action files exist
echo "Listing action files:"
fd . components/runware/actions/
# Then let's search for these properties with proper regex
echo -e "\nSearching for removed properties:"
for prop in "uploadEndpoint" "checkNSFW" "positivePrompt" "negativePrompt" "seedImage" "maskImage" "strength" "model" "steps" "scheduler" "seed"; do
echo -e "\nChecking property: $prop"
rg "\"$prop\":\s*{" components/runware/actions/
done
# Let's also check if there are any new task-specific files
echo -e "\nChecking for task-specific files:"
rg "type:\s*\"action\"" components/runware/actions/
Length of output: 5571
Script:
#!/bin/bash
# Let's check the content of these action files for the properties without regex
echo "Checking image-inference action for generation properties:"
cat components/runware/actions/image-inference/image-inference.mjs
echo -e "\nChecking other actions for specific properties:"
for file in components/runware/actions/*/*.mjs; do
echo -e "\nFile: $file"
# Simple grep for property names without complex regex
grep -E "positivePrompt|negativePrompt|model|steps|scheduler|seed|strength|maskImage|seedImage|checkNSFW" "$file"
done
Length of output: 29283
components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs (1)
107-107: Verify the definition of IMAGE_CONTROL_NET_PREPROCESS in constants.TASK_TYPE
Ensure that constants.TASK_TYPE includes the IMAGE_CONTROL_NET_PREPROCESS value to prevent undefined reference errors during runtime.
Run the following script to confirm:
✅ Verification successful
IMAGE_CONTROL_NET_PREPROCESS is properly defined in constants
The constant is correctly defined in components/runware/common/constants.mjs with both a value and label property, and is being used appropriately in the image-control-net-preprocess action.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that IMAGE_CONTROL_NET_PREPROCESS is defined in constants.TASK_TYPE.
# Test: Search for the definition of IMAGE_CONTROL_NET_PREPROCESS in constants.mjs
# Expect: At least one match showing its definition.
rg 'IMAGE_CONTROL_NET_PREPROCESS' ../../common/constants.mjs
Length of output: 127
Script:
#!/bin/bash
# Let's first find the constants file in the repository
fd constants.mjs
# Then search for IMAGE_CONTROL_NET_PREPROCESS in all files
rg -A 2 "IMAGE_CONTROL_NET_PREPROCESS"
Length of output: 28250
components/runware/actions/image-background-removal/image-background-removal.mjs (2)
62-68: Verify minimum values for alpha matting parameters
The properties alphaMattingForegroundThreshold, alphaMattingBackgroundThreshold, and alphaMattingErodeSize have a min value set to 1. If a value of 0 is acceptable and meaningful for these parameters in the API, consider updating the min to 0 to allow a broader range of inputs.
Also applies to: 70-76, 78-84
5-126: Well-structured implementation of 'Image Background Removal' action
The action is defined correctly with appropriate properties and aligns with the overall design of the Runware actions. The use of propDefinition promotes consistency and reuse of common property definitions. The run method is implemented effectively, adhering to asynchronous best practices.
components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs
Show resolved
Hide resolved
components/runware/actions/image-background-removal/image-background-removal.mjs
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Outside diff range and nitpick comments (9)
components/runware/actions/image-caption/image-caption.mjs (1)
5-11: Consider enhancing the action description.While the current description provides a good overview and documentation link, it could be more helpful to users by including:
- Expected input image formats/requirements
- What kind of captions are generated
- Expected response format
- description: "Request an image caption task to be processed by the Runware API. [See the documentation](https://docs.runware.ai/en/utilities/image-to-text).", + description: "Generate descriptive captions for images using AI. Accepts common image formats (PNG, JPEG) and returns a natural language description of the image content. [See the documentation](https://docs.runware.ai/en/utilities/image-to-text).",components/runware/actions/prompt-enhance/prompt-enhance.mjs (2)
5-10: Consider enhancing the module descriptionWhile the documentation link is helpful, consider adding a brief explanation of what prompt enhancement actually does and its typical use cases. This would make the action more self-documenting.
- description: "Request a prompt enhance task to be processed by the Runware API. [See the documentation](https://docs.runware.ai/en/utilities/prompt-enhancer).", + description: "Improves and expands your input prompt by generating multiple enhanced versions with better clarity and detail. Useful for generating more effective AI image generation prompts. [See the documentation](https://docs.runware.ai/en/utilities/prompt-enhancer).",
11-38: Add input validation and required flags to propsWhile the numeric constraints are well-defined, consider these improvements:
- Mark required fields
- Add validation for the prompt string (e.g., non-empty)
prompt: { type: "string", label: "Prompt", description: "The prompt that you intend to enhance.", + required: true, + minLength: 1, }, promptMaxLength: { type: "integer", label: "Prompt Max Length", description: "Represents the maximum length of the enhanced prompt that you intend to receive. Min `12`, Max `400`.", min: 12, max: 400, + required: true, },components/runware/actions/image-upscale/image-upscale.mjs (1)
31-37: Consider enhancing the upscaleFactor property configuration.The property could benefit from:
- A default value to improve usability
- More detailed examples in the description showing the impact on image dimensions
upscaleFactor: { type: "integer", label: "Upscale Factor", - description: "The level of upscaling performed. Each will increase the size of the image by the corresponding factor. Eg. `2`.", + description: "The level of upscaling performed. Each will increase both dimensions of the image by the corresponding factor. For example, a factor of 2 will double both width and height (e.g., 512x512 → 1024x1024).", min: 2, max: 4, + default: 2, },components/runware/runware.app.mjs (2)
56-60: Consider adding format validation for inputImage.While the description clearly specifies the accepted formats, consider adding runtime validation to ensure the input matches one of the following patterns:
- UUID v4 format
- Data URI format
- Base64 string
- Valid URL format
Here's a suggested implementation:
inputImage: { type: "string", label: "Input Image", description: "Specifies the input image to be processed. The image can be specified in one of the following formats:\n - An UUID v4 string of a [previously uploaded image](https://docs.runware.ai/en/getting-started/image-upload) or a [generated image](https://docs.runware.ai/en/image-inference/api-reference).\n - A data URI string representing the image. The data URI must be in the format `data:<mediaType>;base64,` followed by the base64-encoded image. For example: `data:image/png;base64,iVBORw0KGgo...`.\n - A base64 encoded image without the data URI prefix. For example: `iVBORw0KGgo...`.\n - A URL pointing to the image. The image must be accessible publicly.\nSupported formats are: PNG, JPG and WEBP.", + validate: (value) => { + // UUID v4 validation + const uuidV4Regex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i; + // Data URI validation + const dataUriRegex = /^data:image\/(png|jpg|jpeg|webp);base64,/i; + // URL validation + const urlRegex = /^https?:\/\/.+/i; + + if (uuidV4Regex.test(value)) return true; + if (dataUriRegex.test(value)) return true; + if (urlRegex.test(value)) return true; + // Base64 validation (basic check) + if (/^[A-Za-z0-9+/=]+$/.test(value)) return true; + + throw new Error("Invalid input format. Must be a UUID v4, data URI, base64 string, or URL."); + }, },
Line range hint
1-94: Architecture changes align well with modularization goals.The removal of task-specific properties (like
positivePrompt,negativePrompt,seedImage, etc.) from the main app configuration supports the PR objective of breaking down the single Runware action into specialized actions. The remaining properties are appropriately generic and can be reused across different action types, while the newinputImageproperty provides a flexible input mechanism for various image processing tasks.Consider documenting the relationship between this base configuration and the new specialized actions, perhaps in a README file, to help users understand:
- Which properties are inherited from the base configuration
- Which properties are specific to each specialized action
- How the
inputImageproperty is used across different actionscomponents/runware/actions/image-background-removal/image-background-removal.mjs (2)
37-42: Consider Adding Validation forrgbaValuesTo ensure that the
rgbaarray contains valid numerical values within the expected range (0-255), consider setting thetypeto"integer[]"and addingminandmaxconstraints to each element.
112-112: UseparseIntfor MappingrgbaValuesWhen parsing the
rgbavalues, consider usingparseIntinstead ofparseFloatsince the values represent integer color components.Apply this change to use
parseInt:- rgba: rgba?.map(parseFloat), + rgba: rgba?.map(parseInt),components/runware/actions/image-inference/image-inference.mjs (1)
82-148: Consider moving shared constants outside the functionThe constants defined within
additionalProps, such asseedImage,maskImage, and others, are independent of the function's execution and are the same every time the function is called. Moving them outside the function scope improves readability and avoids redefining them on each function call.Apply this diff to move the constants outside:
+// Define shared constants outside the function +const seedImage = { + type: "string", + label: "Seed Image", + description: "When doing Image-to-Image, Inpainting or Outpainting, this parameter is **required**. Specifies the seed image to be used for the diffusion process. The image can be specified in one of the following formats:\n - An UUID v4 string of a [previously uploaded image](https://docs.runware.ai/en/getting-started/image-upload) or a [generated image](https://docs.runware.ai/en/image-inference/api-reference).\n - A data URI string representing the image. The data URI must be in the format `data:<mediaType>;base64,` followed by the base64-encoded image. For example: `data:image/png;base64,iVBORw0KGgo...`.\n - A base64 encoded image without the data URI prefix. For example: `iVBORw0KGgo...`.\n - A URL pointing to the image. The image must be accessible publicly. Supported formats are: PNG, JPG and WEBP.", +}; + +const maskImage = { + type: "string", + label: "Mask Image", + description: "When doing Inpainting or Outpainting, this parameter is **required**. Specifies the mask image to be used for the inpainting process. The image can be specified in one of the following formats:\n - An UUID v4 string of a [previously uploaded image](https://docs.runware.ai/en/getting-started/image-upload) or a [generated image](https://docs.runware.ai/en/image-inference/api-reference).\n - A data URI string representing the image. The data URI must be in the format `data:<mediaType>;base64,` followed by the base64-encoded image. For example: `data:image/png;base64,iVBORw0KGgo...`.\n - A base64 encoded image without the data URI prefix. For example: `iVBORw0KGgo...`.\n - A URL pointing to the image. The image must be accessible publicly. Supported formats are: PNG, JPG and WEBP.", +}; + +// ... Move other constants similarly ... + export default { // ... existing code ... additionalProps() { const { structure } = this; - const seedImage = { /* ... */ }; - const maskImage = { /* ... */ }; - // ... other constants ... if (structure === constants.IMAGE_INFERENCE_STRUCTURE.IMAGE_TO_IMAGE.value) { return { seedImage, strength, }; } // ... rest of the code ...
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
components/runware/actions/image-background-removal/image-background-removal.mjs(1 hunks)components/runware/actions/image-caption/image-caption.mjs(1 hunks)components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs(1 hunks)components/runware/actions/image-inference/image-inference.mjs(1 hunks)components/runware/actions/image-upscale/image-upscale.mjs(1 hunks)components/runware/actions/prompt-enhance/prompt-enhance.mjs(1 hunks)components/runware/actions/request-task/request-task.mjs(0 hunks)components/runware/common/constants.mjs(1 hunks)components/runware/package.json(1 hunks)components/runware/runware.app.mjs(1 hunks)
💤 Files with no reviewable changes (1)
- components/runware/actions/request-task/request-task.mjs
✅ Files skipped from review due to trivial changes (1)
- components/runware/package.json
🔇 Additional comments (15)
components/runware/actions/image-caption/image-caption.mjs (2)
1-4: LGTM! Imports are well-organized and necessary.
The imports are logically structured and each import serves a clear purpose in the module.
11-25: Verify prop definitions in the app module.
The props are well-structured and reuse definitions from the app module. Let's verify these definitions exist and are properly typed.
✅ Verification successful
Props are properly defined and consistent with the app module
The verification confirms that both inputImage and includeCost props are well-defined in the app module (runware.app.mjs) and are correctly referenced in the component:
inputImageis defined as a string prop with proper label, description, and validationincludeCostis defined as a boolean prop with appropriate label and description- Both props are consistently used across multiple actions in the component
- The prop definitions in the component correctly reference these app-level definitions using
propDefinition
The implementation follows best practices by centralizing prop definitions in the app module and reusing them across actions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the propDefinitions exist in the app module
# Expected: Find definitions for inputImage and includeCost props
# Search for prop definitions in the app module
rg -A 5 "propDefinition.*inputImage|propDefinition.*includeCost" "components/runware/**/*.mjs"
Length of output: 164
Script:
#!/bin/bash
# Let's first find the correct path for the app module
fd -e mjs -e js "app" --type f
# Then search for prop definitions
rg -A 5 "propDefinition.*inputImage|propDefinition.*includeCost"
Length of output: 85482
Script:
#!/bin/bash
# Let's find the app file in the runware component directory
fd -e mjs "runware.app"
# Then search for the prop definitions in the app file
rg -A 5 "inputImage|includeCost" components/runware/
Length of output: 17336
components/runware/common/constants.mjs (2)
31-56: LGTM! Well-structured constant definition.
The IMAGE_INFERENCE_STRUCTURE constant follows consistent patterns with existing code:
- Maintains the value/label pattern
- Uses consistent naming conventions
- Provides clear categorization of image inference subtypes
61-61: LGTM! Clean export addition.
The new constant is properly exported and maintains alphabetical ordering in the exports.
components/runware/actions/prompt-enhance/prompt-enhance.mjs (2)
1-4: LGTM: Imports are appropriate and well-structured
The imports are clean and purposeful, bringing in necessary dependencies for UUID generation, app configuration, and shared constants.
1-65: Verify consistency with other Runware actions
As this is part of breaking down the main Runware action, let's ensure consistency across all new actions.
✅ Verification successful
Structure is consistent across Runware actions
After examining the actions, I can confirm that the prompt-enhance action follows the same consistent structure as other Runware actions. All actions share these common patterns:
- Same import structure (uuid, app, constants)
- Consistent action definition with key, name, description, version, and type
- Common props pattern including the app and includeCost propDefinitions
- Consistent async run method structure with destructuring and app.post call
- Uniform task handling with taskUUID and taskType from constants
- Consistent response and summary export format
The prompt-enhance action maintains this consistency while implementing its specific functionality, making it a well-integrated part of the Runware action collection.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent structure across all new Runware actions
# Test: Check if all action modules follow the same structure
echo "Checking for consistent module structure across actions..."
fd --type f --extension mjs$ . components/runware/actions -x cat {} \; | \
grep -E "^export default {|key:|type: \"action\"|propDefinition|async run\({|taskType:"
# Test: Verify consistent error handling
echo "Checking for error handling patterns..."
fd --type f --extension mjs$ . components/runware/actions -x cat {} \; | \
grep -E "try {|catch \(|throw new Error"
Length of output: 502
Script:
#!/bin/bash
# Let's try a different approach to check the actions directory structure and content
# First, list all action files
echo "=== Listing all action files ==="
fd --type f --extension mjs$ . components/runware/actions
# Then examine each action file's structure
echo -e "\n=== Examining action files structure ==="
for file in $(fd --type f --extension mjs$ . components/runware/actions); do
echo -e "\nFile: $file"
cat "$file"
done
Length of output: 296
Script:
#!/bin/bash
# Let's try using ripgrep to search for files and their content
# First, find all Runware action files
echo "=== Finding Runware action files ==="
rg -l "runware-" --type js components/runware/actions
# Then examine the structure of these files
echo -e "\n=== Action file contents ==="
rg -A 10 "export default {" --type js components/runware/actions
# Check for task types usage
echo -e "\n=== Task type constants usage ==="
rg "TASK_TYPE" --type js components/runware/actions -A 2
# Check for common props and patterns
echo -e "\n=== Common props and patterns ==="
rg "propDefinition|type: \"action\"|async run\(" --type js components/runware/actions
Length of output: 681
Script:
#!/bin/bash
# Let's try a simpler approach with basic commands
echo "=== Listing files in actions directory ==="
ls -R components/runware/actions/
echo -e "\n=== Checking prompt-enhance action content ==="
cat components/runware/actions/prompt-enhance/prompt-enhance.mjs
echo -e "\n=== Checking for other action files ==="
find components/runware/actions -type f -name "*.mjs" -not -path "*/prompt-enhance/*"
Length of output: 3072
Script:
#!/bin/bash
# Let's check one of the image-related actions to compare structure
echo "=== Checking image-caption action structure ==="
cat components/runware/actions/image-caption/image-caption.mjs
echo -e "\n=== Checking image-inference action structure ==="
cat components/runware/actions/image-inference/image-inference.mjs
Length of output: 20076
components/runware/actions/image-upscale/image-upscale.mjs (2)
1-4: LGTM: Imports are appropriate and consistent.
The necessary dependencies are imported with consistent use of .mjs extensions for local modules.
8-8: Verify the documentation link.
The documentation link should be verified to ensure it's accessible and contains relevant information.
✅ Verification successful
Documentation link is accessible and valid ✓
The documentation URL https://docs.runware.ai/en/image-editing/upscaling returns a successful HTTP 200 status code, confirming that the link is valid and accessible.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify if the documentation URL is accessible
# Expected: URL should return a successful status code
curl -s -I "https://docs.runware.ai/en/image-editing/upscaling" | head -n 1
Length of output: 87
components/runware/runware.app.mjs (1)
56-60: LGTM! Well-documented property definition.
The inputImage property is well-documented with clear examples and supported formats, which aligns with the PR objective of creating more specialized actions with clear field requirements.
components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs (2)
1-10: LGTM! Well-structured module metadata with clear documentation.
The imports are appropriate, and the module metadata is well-defined with a helpful documentation link.
1-4: Verify constant definition and app integration.
Let's verify that the task type constant is properly defined and the app integration is set up correctly.
Also applies to: 107-107
components/runware/actions/image-background-removal/image-background-removal.mjs (4)
1-3: Proper Imports of Required Modules
The necessary modules uuid, app, and constants are correctly imported, ensuring that the action has access to all required functionalities.
6-10: Action Metadata Defined Appropriately
The action's key, name, description, version, and type are properly specified, facilitating correct identification and usage within the system.
13-84: Well-Defined Properties with Clear Descriptions
All properties are accurately defined with appropriate types, labels, and descriptions. Optional properties are correctly marked, and ranges are specified where necessary.
86-125: run Method Correctly Constructs and Sends the API Request
The run method appropriately destructures the properties, constructs the request payload, and sends it using app.post. The response is handled correctly, and a summary message is exported.
components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs
Show resolved
Hide resolved
components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs
Show resolved
Hide resolved
jcortes
force-pushed
the
runware-individual-actions-endpoint
branch
from
cc1a264
to
29d5c52
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (5)
components/runware/actions/image-caption/image-caption.mjs (1)
11-25: Consider adding input validation for the props.While the props are well-structured using propDefinitions, consider adding explicit validation or type checking for
inputImageto ensure it meets the required format before making the API call.inputImage: { propDefinition: [ app, "inputImage", ], + validate: (value) => { + if (!value || typeof value !== 'string') { + throw new Error('Input image must be a non-empty string'); + } + return value; + }, },components/runware/actions/prompt-enhance/prompt-enhance.mjs (2)
1-10: LGTM! Consider enhancing the documentation.The module definition and imports look good. The documentation link is helpful, but consider adding example usage in the description.
- description: "Request a prompt enhance task to be processed by the Runware API. [See the documentation](https://docs.runware.ai/en/utilities/prompt-enhancer).", + description: "Request a prompt enhance task to be processed by the Runware API. Example: Enhance a product description for better engagement. [See the documentation](https://docs.runware.ai/en/utilities/prompt-enhancer).",
11-38: LGTM! Consider adding input validation for prompt.The props are well-defined with appropriate constraints. However, the
promptprop could benefit from some basic validation.prompt: { type: "string", label: "Prompt", description: "The prompt that you intend to enhance.", + minLength: 1, + maxLength: 1000, },components/runware/actions/image-upscale/image-upscale.mjs (1)
5-10: Consider starting with version 1.0.0.The metadata is well-structured with clear description and documentation link. However, since this is a production-ready feature (part of breaking down an existing functionality), consider starting with version 1.0.0 instead of 0.0.1.
- version: "0.0.1", + version: "1.0.0",components/runware/runware.app.mjs (1)
Line range hint
1-94: Consider adding validation for image dimensions.The
heightandwidthproperties have validation for min/max values but could benefit from additional validation to ensure values are divisible by 64 as mentioned in the description.Consider adding a validator function:
// Add to methods section validateDimension(value) { if (value % 64 !== 0) { throw new Error("Dimension must be divisible by 64"); } return true; },Then update the dimension properties:
height: { type: "integer", label: "Height", description: "Used to define the height dimension of the generated image. Certain models perform better with specific dimensions. The value must be divisible by 64, eg: `512`, `576`, `640` ... `2048`.", min: 512, max: 2048, + validate: "validateDimension", },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
components/runware/actions/image-background-removal/image-background-removal.mjs(1 hunks)components/runware/actions/image-caption/image-caption.mjs(1 hunks)components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs(1 hunks)components/runware/actions/image-inference/image-inference.mjs(1 hunks)components/runware/actions/image-upscale/image-upscale.mjs(1 hunks)components/runware/actions/prompt-enhance/prompt-enhance.mjs(1 hunks)components/runware/actions/request-task/request-task.mjs(0 hunks)components/runware/common/constants.mjs(1 hunks)components/runware/package.json(1 hunks)components/runware/runware.app.mjs(1 hunks)
💤 Files with no reviewable changes (1)
- components/runware/actions/request-task/request-task.mjs
🚧 Files skipped from review as they are similar to previous changes (2)
- components/runware/common/constants.mjs
- components/runware/package.json
🔇 Additional comments (15)
components/runware/actions/image-caption/image-caption.mjs (3)
1-3: LGTM! Imports are well-organized.
The necessary dependencies are properly imported, using the uuid package for generating unique IDs and maintaining constants in a common location.
26-47:
Add error handling and response validation as previously suggested.
The implementation needs error handling and response validation as highlighted in the previous review. The existing comment about implementing try-catch and response validation is still applicable.
5-10: LGTM! Action metadata is well-defined.
The action configuration is clear and follows conventions. Please verify that the documentation link is accessible and points to the correct page.
✅ Verification successful
Documentation link is accessible and returns a successful response
The documentation URL https://docs.runware.ai/en/utilities/image-to-text returns HTTP 200, confirming it's accessible. The action metadata is well-structured and the documentation link is valid.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the documentation link is accessible
# Note: This is a basic check. A manual verification is still recommended.
curl -s -I "https://docs.runware.ai/en/utilities/image-to-text" | head -n 1
Length of output: 87
components/runware/actions/prompt-enhance/prompt-enhance.mjs (2)
39-64: Error handling comment already exists.
A previous review comment already addresses the need for error handling and response validation in this section.
1-65: Verify consistency across new action modules.
Let's ensure this module follows the same patterns as other new action modules.
✅ Verification successful
Consistent patterns confirmed across action modules
The analysis shows strong consistency across all action modules:
- All actions follow identical import patterns (uuid, app, constants)
- All actions implement the same async run method structure with consistent parameter destructuring and response handling
- All actions are properly typed as "action"
- Common props pattern with
includeCostbeing consistently used
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent patterns across new action modules
# Expected: Similar structure in other action modules (props, run method)
# Find all new action modules
echo "Checking for consistent patterns across action modules..."
fd --type f --extension mjs$ . components/runware/actions -x grep -l "type: \"action\""
# Check for consistent prop patterns
echo -e "\nChecking prop patterns..."
fd --type f --extension mjs$ . components/runware/actions -x grep -A 2 "propDefinition: \["
# Check for consistent run method patterns
echo -e "\nChecking run method patterns..."
fd --type f --extension mjs$ . components/runware/actions -x grep -A 3 "async run"
Length of output: 543
Script:
#!/bin/bash
# Let's try a different approach to find and analyze action files
# Find all .mjs files in actions directory
echo "=== Finding all .mjs files in actions directory ==="
fd --type f --extension mjs$ . components/runware/actions
# For each file found, show its content to analyze structure
echo -e "\n=== Analyzing structure of action files ==="
fd --type f --extension mjs$ . components/runware/actions -x cat
Length of output: 346
Script:
#!/bin/bash
# Let's try using ripgrep for more detailed analysis
# Find files containing action type definition
echo "=== Action files ==="
rg -l "type: \"action\"" components/runware/actions/
# Show the structure of these files
echo -e "\n=== Action file structures ==="
rg -A 50 "export default {" components/runware/actions/
# Look for common patterns in imports
echo -e "\n=== Common imports ==="
rg "^import" components/runware/actions/
# Look for prop definitions
echo -e "\n=== Prop definitions ==="
rg -A 5 "props: {" components/runware/actions/
# Look for run method implementations
echo -e "\n=== Run method implementations ==="
rg -A 10 "async run\(" components/runware/actions/
Length of output: 8869
components/runware/actions/image-upscale/image-upscale.mjs (3)
1-3: LGTM! Imports are well-organized and necessary.
All imports are being used appropriately in the code.
11-44: LGTM! Props are well-defined with appropriate constraints.
The props definition is comprehensive and includes all necessary fields for image upscaling. The upscaleFactor constraints (2-4x) are reasonable and well-documented.
45-72: Add error handling and input validation.
The implementation is clean but needs additional robustness:
- Input validation before API call
- Error handling for API requests
- Response structure validation
The previous review comments about error handling are still valid. Please refer to the suggested implementation in the past review comments.
components/runware/runware.app.mjs (2)
56-60: Well-structured implementation of the inputImage property.
The property definition is comprehensive and clearly documents all supported input formats. The description provides excellent examples for each format type, making it user-friendly.
Line range hint 1-94: Verify the removal of task-specific properties.
The removal of properties like positivePrompt, negativePrompt, seedImage, etc., aligns with the PR objective of breaking down the Runware action into specialized actions. However, we should verify that these properties are properly relocated to their respective new action modules.
✅ Verification successful
Removed properties have been properly relocated to specialized actions
The verification confirms that the removed properties from runware.app.mjs have been correctly relocated to their respective specialized action modules:
- Properties like
positivePrompt,negativePrompt,seedImage,maskImage,strength,model,steps, andseedare now properly defined incomponents/runware/actions/image-inference/image-inference.mjs - The properties are appropriately scoped based on the inference structure (Text-to-Image, Image-to-Image, In/Out Painting, etc.)
- Common properties like
height,width,includeCostremain in the app file as they are shared across multiple actions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that removed properties exist in new specialized action modules
# Expected: Find these properties in new action-specific files
echo "Searching for removed properties in new action modules..."
for property in "uploadEndpoint" "checkNSFW" "positivePrompt" "negativePrompt" "seedImage" "maskImage" "strength" "model" "steps" "seed"; do
echo "Checking for property: $property"
rg -l "$property" --type js
done
Length of output: 2547
Script:
#!/bin/bash
# Let's try a different approach to find the specialized action modules
# First, find all action files in the components/runware directory
echo "Finding action files in runware component..."
fd "actions" --type f --extension mjs components/runware
# Then, let's examine their content for property definitions
echo -e "\nChecking content of action files..."
for file in $(fd "actions" --type f --extension mjs components/runware); do
echo -e "\n=== Content of $file ==="
cat "$file"
done
Length of output: 300
Script:
#!/bin/bash
# Let's try a different approach by looking at the entire runware component directory
echo "Listing all files in runware component..."
fd . components/runware --type f
echo -e "\nChecking for specialized action files with different naming patterns..."
rg -l "type: \"action\"" --type js components/runware/
Length of output: 860
Script:
#!/bin/bash
# Let's examine the content of these specialized action files
echo "=== Checking image-inference action (most likely to contain the removed properties) ==="
cat components/runware/actions/image-inference/image-inference.mjs
echo -e "\n=== Checking image-control-net-preprocess action ==="
cat components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs
Length of output: 22258
components/runware/actions/image-inference/image-inference.mjs (3)
1-4: LGTM!
The imports are appropriate and well-organized.
67-71: Skip comment: Property type issue already reported
A previous review already suggested changing the 'seed' property type from string to integer.
95-99: Skip comment: Property type issues already reported
Previous reviews already suggested changing the 'strength' and 'CFGScale' property types from string to number.
Also applies to: 189-193
components/runware/actions/image-control-net-preprocess/image-control-net-preprocess.mjs (1)
1-126: Well-structured implementation of the Image Control Net Preprocess action
The code is neatly organized and follows the established patterns in the codebase. This modular approach enhances maintainability and readability.
components/runware/actions/image-background-removal/image-background-removal.mjs (1)
1-126: LGTM: The action is well-defined and the code is structured appropriately
The module implementation is clear and follows best practices. The action properties are well-defined, and the API request is properly constructed.
components/runware/actions/image-background-removal/image-background-removal.mjs
Show resolved
Hide resolved
WHY
Resolves #14579
Summary by CodeRabbit
Release Notes
New Features
Improvements
inputImageproperty for image processing tasks.Version Update
0.1.0to0.2.0.