RAGFLOW has an ExeSQL in the Agent module. How can I execute the ExeSQL without being limited in the length of the result?

[zhaoxdq]

For example, if I want to query 500 rows of data in a SQL, when I submit it to ExeSQL, the SQL is correct, but the query result is only 30 rows. What is the reason and how to configure it?

[dosubot[bot]]

Hi @zhaoxdq! I'm Dosu and I’m helping the ragflow team.

The reason you're only getting 30 rows from ExeSQL is because the Agent module uses a parameter called top_n to limit the number of rows returned, and its default value is 30. You can increase this limit by setting the top_n parameter to a higher value when you configure or instantiate the ExeSQL component. For example, in the workflow DSL or test scenarios, you can set "top_n": 500 to get 500 rows. In the frontend, the ExeSQLForm uses a TopNItem with an initial value of 30 and a max of 1000, which you can adjust as needed. If you need more than 1000 rows, check for any server-side constraints that might enforce a maximum value, but modifying top_n is the intended way to control the result size in ExeSQL reference reference.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[dosubot[bot]]

This happens because the sandbox container pool has a fixed size (controlled by SANDBOX_EXECUTOR_MANAGER_POOL_SIZE). When all containers are busy running tasks, new requests have to wait for a free container. If none become available within the timeout (SANDBOX_TIMEOUT, default 10s), you get a timeout error. This is expected when the pool is saturated by many concurrent or long-running tasks details pool logic.

To fix or reduce this, you can: increase SANDBOX_EXECUTOR_MANAGER_POOL_SIZE (and restart the service), make sure your system has enough CPU/memory for more containers, and check logs for stuck or unreleased containers. If your tasks are slow, try increasing SANDBOX_TIMEOUT as well config example. If you still see timeouts after these changes, check for errors in the sandbox-executor-manager logs—sometimes containers crash or get stuck and need to be restarted.

Let me know your current pool size and if you see any errors in the logs around the timeouts—this can help pinpoint if it's just pool exhaustion or something else.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[zhaoxdq]

@dosu I want to know if I report this error Error: Internal error in sanbox: HTTPConnectionPool(host='sandbox-executor-manager', port=9385): Read timed out. (read timeout=10) and then I have to restart, because after I report the error, all subsequent requests are timed out

[dosubot[bot]]

Yes, if you see this timeout error and then all subsequent requests also time out, you do need to manually restart the sandbox-executor-manager service to recover. This happens because the container pool can become exhausted or deadlocked, and there is no built-in global recovery or self-healing—only individual containers are checked and recreated, but if the whole pool is stuck, only a restart will clear it. This is the intended design and is documented in both the code and the FAQ. To help prevent this, monitor your resource usage, consider increasing SANDBOX_EXECUTOR_MANAGER_POOL_SIZE and SANDBOX_TIMEOUT if needed, and watch logs for early signs of pool exhaustion or stuck containers. Any config changes also require a full restart to take effect.
Reference: FAQ and codebase
Reference: container pool logic and recovery

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[zhaoxdq]

@dosu How can I intercept my question in the agent of ragflow and then call ai to generate the answer, but I cannot call the code component in my process, what else can I do

[zhaoxdq]

@dosu

[onestardao]

you’re likely hitting a layered limitation that goes beyond just the sandbox pool or timeout configs.

this kind of “post-timeout executor collapse” is a classic case of what we cataloged in our AI infra failure map — specifically what we call a predeploy-collapse (also known as No.15 in our problem map).

even after adjusting container pool and timeouts, many systems still break silently due to improper bootstrap ordering or misaligned internal state.

we had to build a dedicated reasoning layer just to prevent this from spiraling in agent pipelines.

if you’re curious, feel free to ping me and i’ll share the link — it’s all MIT licensed, backed by tesseract.js author, and focused on actual fixes, not guesswork.