CodeExecutionBlock split into InstantiationBlock & StepExecutionBlock

[mariosacaj]

Especially in case of heavy sandbox customization we don't want to spawn a new VM every time we need to execute code, especially in circumstances when time of inactivity is negligible.

Changes 🏗️

Added two now blocks inside autogpt_platform/backend/backend/blocks/code_executor.py which split the logic of the CodeExecutionBlock in two parts: InstantiationBlock and StepExecutionBlock.

The overall setup shall be the done in the InstantiationBlock which then passes as output the sandbox_id which identifies the sandbox instance.

At a later stage any line of code can be executed through StepExecutionBlock inside the same instance using the e2b library function sandbox = Sandbox.connect(sandbox_id=sandbox_id, api_key=api_key). Variables and memory form earlier executions or instantiation are persisted.

Beware, this approach does not make use of the beta apis to pause and resume an instance. By using the approach above the VM will likely be killed after the timeout inactivity set at instantiation time.

New Features:

• InstantiationBlock Class:

  • Added a new class to instantiate an isolated sandbox environment with internet access for code execution. This class includes input and output schemas, methods for running and executing code, and handles sandbox setup commands and code execution.

• StepExecutionBlock Class:

  • Introduced a new class to execute code in a previously instantiated sandbox environment. This class also includes input and output schemas, methods for running and executing step code, and handles connecting to an existing sandbox for code execution.

Minor Changes:

• ProgrammingLanguage Enum:
  • Added a blank line for better readability within the ProgrammingLanguage enum definition.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

This PR targets the master branch but does not come from dev or a hotfix/* branch.

Automatically setting the base branch to dev.

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪

🧪 PR contains tests

🔒 Security concerns Code Execution: The blocks allow arbitrary code execution in sandboxed environments. While sandboxed, there's no validation or restriction on the code being executed, which could potentially be used for malicious purposes if the sandbox environment is not properly isolated. Consider adding code validation or execution restrictions.

⚡ Recommended focus areas for review Resource Cleanup The InstantiationBlock's execute_code method creates a sandbox but doesn't handle cleanup if an error occurs during setup_commands execution. This could lead to orphaned sandbox instances. # Running setup commands for cmd in setup_commands: sandbox.commands.run(cmd) Error Handling The StepExecutionBlock doesn't verify if the sandbox is still active before executing code. Since sandbox instances can timeout, this could lead to runtime errors. sandbox = Sandbox.connect(sandbox_id=sandbox_id, api_key=api_key) if not sandbox: raise Exception("Sandbox not found") Timeout Management The StepExecutionBlock doesn't have a timeout parameter for code execution, which could lead to long-running or infinite loops in the sandbox. execution = sandbox.run_code( code, language=language.value )

[netlify]

✅ Deploy Preview for auto-gpt-docs canceled.

Name	Link
🔨 Latest commit	44008f7
🔍 Latest deploy log	https://app.netlify.com/sites/auto-gpt-docs/deploys/6773f9eea4fdff000803a74c

[netlify]

✅ Deploy Preview for auto-gpt-docs-dev canceled.

Name	Link
🔨 Latest commit	44008f7
🔍 Latest deploy log	https://app.netlify.com/sites/auto-gpt-docs-dev/deploys/6773f9ee10a8ea0008dc4039