-
Notifications
You must be signed in to change notification settings - Fork 518
feat: optimize sandbox bad cases #1869
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
Conversation
WalkthroughA new warning propagation system has been added to the sandbox execution pipeline. A utility function extracts warnings from executor logs, which flow through the DTO layer and agent-tools package to be included in the final API response. Summary field generation has been removed, and a development script for Node debugging has been added. Changes
Sequence DiagramsequenceDiagram
participant Executor as Executor/Log
participant Utils as scalebox.utils
participant DTO as scalebox.dto
participant AgentTools as agent-tools<br/>sandbox.ts
participant Client as API Client
Executor->>Utils: executor log with [WARN] entries
Utils->>Utils: extractWarnings()
Utils-->>DTO: warning strings []
DTO->>DTO: ScaleboxResponseFactory.success()
DTO-->>AgentTools: sandbox result with warnings
AgentTools->>AgentTools: propagate warnings to response
AgentTools-->>Client: SandboxExecuteResponse with warnings field
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
packages/agent-tools/src/builtin/sandbox.ts (2)
104-110: Remove summary field to align with PR objectives.The summary field is still present in this error response, but according to the AI summary and PR objectives, summary fields should be removed from all error paths. Other error responses in this file (lines 141, 167) correctly omit the summary field.
Apply this diff:
return { status: 'error', error: 'Sandbox service is not available', - summary: '[SYSTEM_ERROR] Sandbox service is not configured.', };
171-187: Remove summary field and commented-out code.Two issues in this method:
- Line 176: The summary field is still present but should be removed per PR objectives (summary fields removed from all error paths).
- Line 185: Commented-out code violates the coding guideline to remove unused code, dead code, and commented-out code.
Apply this diff:
if (!errors || errors.length === 0) { return { status: 'error', error: 'Unknown system error', - summary: '[SYSTEM_ERROR] Unknown system error', }; } const errorMessages = errors.map((e) => e.message || e.code || 'Unknown').join('; '); return { status: 'error', error: errorMessages, - // summary, };
🧹 Nitpick comments (2)
packages/agent-tools/src/builtin/sandbox.ts (1)
132-153: Consider defaulting warnings to an empty array.The optional chaining is used correctly. However, when
warningsis undefined, it will be included in the return object aswarnings: undefined. For better API consistency, consider defaulting to an empty array.Apply this diff:
- const warnings = result.data?.warnings; + const warnings = result.data?.warnings ?? [];This ensures the field is always an array type, which can simplify client-side handling.
apps/api/src/modules/tool/sandbox/scalebox.dto.ts (1)
197-212: Warning propagation correctly implemented; optional refactoring suggested for cleaner property omission pattern.The logic safely extracts warnings from executor logs and includes them in the response. The
extractWarningsfunction properly handles undefined logs by returning an empty array, and thewarnings?: Array<string>field is correctly defined inSandboxExecuteResponse.Optional refinement: Setting
warningstoundefinedwhen empty is valid but less idiomatic than omitting the property. Consider using the spread operator for cleaner code:- warnings: warnings.length > 0 ? warnings : undefined, + ...(warnings.length > 0 && { warnings }),This pattern is more consistent with optional property handling in TypeScript and reduces serialization overhead by omitting the property entirely rather than setting it to
undefined.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
apps/api/package.json(1 hunks)apps/api/src/modules/tool/sandbox/scalebox.dto.ts(3 hunks)apps/api/src/modules/tool/sandbox/scalebox.utils.ts(1 hunks)packages/agent-tools/src/builtin/sandbox.ts(4 hunks)packages/openapi-schema/schema.yml(1 hunks)packages/openapi-schema/src/schemas.gen.ts(1 hunks)packages/openapi-schema/src/types.gen.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (14)
**/*.{js,ts,jsx,tsx,css,json}
📄 CodeRabbit inference engine (.cursor/rules/04-code-formatting.mdc)
Maximum line length of 100 characters
Files:
apps/api/package.jsonapps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{js,ts,jsx,tsx,css,json,yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/04-code-formatting.mdc)
Use 2 spaces for indentation, no tabs
Files:
apps/api/package.jsonapps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.tspackages/openapi-schema/schema.yml
**/*.{js,ts,jsx,tsx,css,json,yml,yaml,md}
📄 CodeRabbit inference engine (.cursor/rules/04-code-formatting.mdc)
No trailing whitespace at the end of lines
Files:
apps/api/package.jsonapps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.tspackages/openapi-schema/schema.yml
**/*.{tsx,ts,json}
📄 CodeRabbit inference engine (.cursor/rules/09-i18n-guidelines.mdc)
Support dynamic content with placeholders in translations
Files:
apps/api/package.jsonapps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursorrules)
**/*.{js,ts,jsx,tsx}: Always use optional chaining (?.) when accessing object properties
Always use nullish coalescing (??) or default values for potentially undefined values
Always check array existence before using array methods
Always validate object properties before destructuring
Always use single quotes for string literals in JavaScript/TypeScript code
**/*.{js,ts,jsx,tsx}: Use semicolons at the end of statements
Include spaces around operators (e.g.,a + binstead ofa+b)
Always use curly braces for control statements
Place opening braces on the same line as their statement
**/*.{js,ts,jsx,tsx}: Group import statements in order: React/framework libraries, third-party libraries, internal modules, relative path imports, type imports, style imports
Sort imports alphabetically within each import group
Leave a blank line between import groups
Extract complex logic into custom hooks
Use functional updates for state (e.g.,setCount(prev => prev + 1))
Split complex state into multiple state variables rather than single large objects
Use useReducer for complex state logic instead of multiple useState calls
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{js,ts,tsx,jsx,py,java,cpp,c,cs,rb,go,rs,php,swift,kt,scala,r,m,mm,sql}
📄 CodeRabbit inference engine (.cursor/rules/00-language-priority.mdc)
**/*.{js,ts,tsx,jsx,py,java,cpp,c,cs,rb,go,rs,php,swift,kt,scala,r,m,mm,sql}: All code comments MUST be written in English
All variable names, function names, class names, and other identifiers MUST use English words
Comments should be concise and explain 'why' rather than 'what'
Use proper grammar and punctuation in comments
Keep comments up-to-date when code changes
Document complex logic, edge cases, and important implementation details
Use clear, descriptive names that indicate purpose
Avoid abbreviations unless they are universally understood
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{js,ts,tsx,jsx}
📄 CodeRabbit inference engine (.cursor/rules/00-language-priority.mdc)
Use JSDoc style comments for functions and classes in JavaScript/TypeScript
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/01-code-style.mdc)
**/*.{js,jsx,ts,tsx}: Use single quotes for string literals in TypeScript/JavaScript
Always use optional chaining (?.) when accessing object properties in TypeScript/JavaScript
Always use nullish coalescing (??) or default values for potentially undefined values in TypeScript/JavaScript
Always check array existence before using array methods in TypeScript/JavaScript
Validate object properties before destructuring in TypeScript/JavaScript
Use ES6+ features like arrow functions, destructuring, and spread operators in TypeScript/JavaScript
Avoid magic numbers and strings - use named constants in TypeScript/JavaScript
Use async/await instead of raw promises for asynchronous code in TypeScript/JavaScript
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/03-typescript-guidelines.mdc)
**/*.{ts,tsx}: Avoid usinganytype whenever possible - useunknowntype instead with proper type guards
Always define explicit return types for functions, especially for public APIs
Prefer extending existing types over creating entirely new types
Use TypeScript utility types (Partial<T>,Pick<T, K>,Omit<T, K>,Readonly<T>,Record<K, T>) to derive new types
Use union types and intersection types to combine existing types
Always import types explicitly using theimport typesyntax
Group type imports separately from value imports
Minimize creating local type aliases for imported types
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{css,scss,sass,less,js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/09-design-system.mdc)
**/*.{css,scss,sass,less,js,jsx,ts,tsx}: Primary color (#155EEF) should be used for main brand color in buttons, links, and accents
Error color (#F04438) should be used for error states and destructive actions
Success color (#12B76A) should be used for success states and confirmations
Warning color (#F79009) should be used for warnings and important notifications
Info color (#0BA5EC) should be used for informational elements
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{tsx,ts}
📄 CodeRabbit inference engine (.cursor/rules/09-i18n-guidelines.mdc)
**/*.{tsx,ts}: Use the translation wrapper component and useTranslation hook in components
Ensure all user-facing text is translatable
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{tsx,ts,jsx,js,vue,css,scss,less}
📄 CodeRabbit inference engine (.cursor/rules/11-ui-design-patterns.mdc)
**/*.{tsx,ts,jsx,js,vue,css,scss,less}: Use the primary blue (#155EEF) for main UI elements, CTAs, and active states
Use red (#F04438) only for errors, warnings, and destructive actions
Use green (#12B76A) for success states and confirmations
Use orange (#F79009) for warning states and important notifications
Use blue (#0BA5EC) for informational elements
Primary buttons should be solid with the primary color
Secondary buttons should have a border with transparent or light background
Danger buttons should use the error color
Use consistent padding, border radius, and hover states for all buttons
Follow fixed button sizes based on their importance and context
Use consistent border radius (rounded-lg) for all cards
Apply light shadows (shadow-sm) for card elevation
Maintain consistent padding inside cards (p-4orp-6)
Use subtle borders for card separation
Ensure proper spacing between card elements
Apply consistent styling to all form inputs
Use clear visual indicators for focus, hover, and error states in form elements
Apply proper spacing between elements using 8px, 16px, 24px increments
Ensure proper alignment of elements (left, center, or right)
Use responsive layouts that work across different device sizes
Maintain a minimum contrast ratio of 4.5:1 for text
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{tsx,ts,jsx,js,vue}
📄 CodeRabbit inference engine (.cursor/rules/11-ui-design-patterns.mdc)
**/*.{tsx,ts,jsx,js,vue}: Include appropriate loading states for async actions in buttons
Group related form elements with appropriate spacing
Provide clear validation feedback for forms
Ensure proper labeling and accessibility for form elements
Ensure all interactive elements are keyboard accessible
Include appropriate ARIA attributes for complex components
Provide alternative text for images and icons
Support screen readers with semantic HTML elements
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/08-contributing-guidelines.mdc)
**/*.{ts,tsx,js,jsx}: Follow the TypeScript/JavaScript style guidelines
Ensure code is well-tested and documented
Files:
apps/api/src/modules/tool/sandbox/scalebox.utils.tspackages/openapi-schema/src/schemas.gen.tsapps/api/src/modules/tool/sandbox/scalebox.dto.tspackages/agent-tools/src/builtin/sandbox.tspackages/openapi-schema/src/types.gen.ts
🧠 Learnings (1)
📚 Learning: 2025-11-25T03:04:51.017Z
Learnt from: CR
Repo: refly-ai/refly PR: 0
File: .cursor/rules/10-testing-guidelines.mdc:0-0
Timestamp: 2025-11-25T03:04:51.017Z
Learning: Applies to **/*.{test,spec}.{ts,tsx,js,jsx} : Use Vitest for unit and integration tests
Applied to files:
apps/api/package.json
🧬 Code graph analysis (1)
apps/api/src/modules/tool/sandbox/scalebox.dto.ts (1)
apps/api/src/modules/tool/sandbox/scalebox.utils.ts (1)
extractWarnings(75-83)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build / Build
🔇 Additional comments (6)
packages/agent-tools/src/builtin/sandbox.ts (1)
43-58: LGTM!The documentation updates are clear and well-structured. The emphasis on treating warnings strictly aligns with the PR's objective to optimize sandbox bad cases, and the package additions are properly documented.
packages/openapi-schema/schema.yml (1)
9111-9144: SandboxExecuteResponse.warnings field looks good and is schema‑compatible.The new
warningsstring array is well-described, optional, and consistent with the existing response shape and YAML style.apps/api/src/modules/tool/sandbox/scalebox.dto.ts (1)
11-11: LGTM! Clean import of the warning extraction utility.The import is properly structured and the utility function is correctly defined in the utils file.
packages/openapi-schema/src/schemas.gen.ts (1)
6744-6751: Sandbox warnings field looks correct and consistentThe new
warningsproperty is correctly modeled as an optionalstring[], its description matches the intended sandbox system warnings behavior, and its structure is consistent with the surroundingdataproperties. No changes needed here (assuming the OpenAPI source andtypes.gen.tswere regenerated from the same spec).apps/api/src/modules/tool/sandbox/scalebox.utils.ts (1)
65-83: LGTM! Clean implementation of warning extraction.The function correctly:
- Handles undefined input with early return
- Filters lines by [WARN] prefix
- Strips the prefix and trims whitespace
- Removes empty strings with final filter
packages/openapi-schema/src/types.gen.ts (1)
4853-4856: Auto-generated type looks correct.The optional
warningsfield is properly typed and documented. Since this is an auto-generated file from OpenAPI schema, the source schema definition should be the primary review target.
| "sync-db-schema": "prisma format && prisma generate && node -r ts-node/register --env-file=.env src/scripts/sync-db-schema.ts", | ||
| "dev": "prisma format && prisma generate && nodemon src/main.ts", | ||
| "dev:debug": "nodemon --inspect src/main.ts", | ||
| "dev:node": "node --trace-warnings --inspect=0.0.0.0:9229 -r ts-node/register -r tsconfig-paths/register src/main.ts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
cat -n apps/api/package.json | sed -n '20,30p'Repository: refly-ai/refly
Length of output: 982
Line exceeds 100-character limit; remove or restrict debugger binding.
Line 24 exceeds the 100-character limit for JSON files. Additionally, binding the debugger to 0.0.0.0:9229 exposes the debug port to all network interfaces. Never have the debugger listen on a public IP address; if remote debugging is needed, use SSH tunnels instead.
Shorten the script or split it across multiple configuration entries. For secure remote debugging, use SSH tunnelling rather than binding to 0.0.0.0.
🤖 Prompt for AI Agents
In apps/api/package.json around line 24, the npm script "dev:node" exceeds the
100-character limit and binds the debugger to 0.0.0.0:9229 which exposes the
port publicly; shorten or split the script into multiple npm scripts (e.g.,
separate flags into "dev:node" and "dev:node:inspect" or use an env var) so the
line stays under 100 chars, and change the debugger binding to localhost
(127.0.0.1:9229) or remove the --inspect host part entirely for local
development; if remote debugging is required, document using SSH tunneling
rather than binding to 0.0.0.0.
Summary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.