[PR #152] [MERGED] fix: propagate container lookup error in GetTool #193

New Issue

2026-06-06T22:09:38-04:00

yindo commented

2026-06-06 22:09:38 -04:00

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/152
Author: @mason5052
Created: 2/26/2026
Status: ✅ Merged
Merged: 3/2/2026
Merged by: @asdek

Base: feature/next_release ← Head: fix/silent-error-handling-gettool

📝 Commits (1)

5720402 fix: propagate container lookup error in GetTool for terminal/file tools

📊 Changes

1 file changed (+8 additions, -2 deletions)

View changed files

📝 backend/cmd/ftester/worker/executor.go (+8 -2)

📄 Description

Description

Problem

GetTool() in executor.go silently ignores errors from GetFlowPrimaryContainer (lines 99-102). When the container lookup fails, containerID remains 0 and containerLID remains "". These invalid values are passed to NewTerminalTool, which later produces cryptic downstream errors like "container is not running" or Docker API errors about invalid container references.

The real root cause (missing/unreachable primary container) is hidden from the user.

Solution

Only call GetFlowPrimaryContainer when the tool actually requires a container (TerminalToolName, FileToolName)
If the lookup fails, return the error immediately with flow ID context
All other tools (15+) skip the unnecessary DB call entirely

Closes #145

Type of Change

Bug fix (non-breaking change which fixes an issue)

Areas Affected

Core Services (Backend API / Workers)
AI Agents (Tool Executor)

Testing

Configuration

Local code review + CI validation

Steps to Reproduce the Bug

Run ftester with a flow that has no primary container assigned
Attempt to use the Terminal or File tool
Observe cryptic errors like "container is not running" instead of "failed to get primary container for flow N"

Expected Result After Fix

Terminal/File tools: clear error "failed to get primary container for flow {id}: {cause}"
All other tools: no change in behavior (container lookup was unnecessary for them)

Security Considerations

No security impact; this is an error handling improvement
No new dependencies or attack surface

Checklist

My code follows the project's coding standards
I have performed a self-review of my code
New and existing tests pass with my changes
My changes generate no new warnings
I have checked my code for potential security vulnerabilities
My changes are backward compatible

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/vxcontrol/pentagi/pull/152 **Author:** [@mason5052](https://github.com/mason5052) **Created:** 2/26/2026 **Status:** ✅ Merged **Merged:** 3/2/2026 **Merged by:** [@asdek](https://github.com/asdek) **Base:** `feature/next_release` ← **Head:** `fix/silent-error-handling-gettool` --- ### 📝 Commits (1) - [`5720402`](https://github.com/vxcontrol/pentagi/commit/5720402301ac6fedadb2005f592e877436f81fda) fix: propagate container lookup error in GetTool for terminal/file tools ### 📊 Changes **1 file changed** (+8 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `backend/cmd/ftester/worker/executor.go` (+8 -2) </details> ### 📄 Description ## Description ### Problem `GetTool()` in `executor.go` silently ignores errors from `GetFlowPrimaryContainer` (lines 99-102). When the container lookup fails, `containerID` remains `0` and `containerLID` remains `""`. These invalid values are passed to `NewTerminalTool`, which later produces cryptic downstream errors like "container is not running" or Docker API errors about invalid container references. The real root cause (missing/unreachable primary container) is hidden from the user. ### Solution - Only call `GetFlowPrimaryContainer` when the tool actually requires a container (`TerminalToolName`, `FileToolName`) - If the lookup fails, return the error immediately with flow ID context - All other tools (15+) skip the unnecessary DB call entirely Closes #145 ## Type of Change - [x] Bug fix (non-breaking change which fixes an issue) ## Areas Affected - [x] Core Services (Backend API / Workers) - [x] AI Agents (Tool Executor) ## Testing ### Configuration - Local code review + CI validation ### Steps to Reproduce the Bug 1. Run ftester with a flow that has no primary container assigned 2. Attempt to use the Terminal or File tool 3. Observe cryptic errors like "container is not running" instead of "failed to get primary container for flow N" ### Expected Result After Fix - Terminal/File tools: clear error "failed to get primary container for flow {id}: {cause}" - All other tools: no change in behavior (container lookup was unnecessary for them) ## Security Considerations - No security impact; this is an error handling improvement - No new dependencies or attack surface ## Checklist - [x] My code follows the project's coding standards - [x] I have performed a self-review of my code - [x] New and existing tests pass with my changes - [x] My changes generate no new warnings - [x] I have checked my code for potential security vulnerabilities - [x] My changes are backward compatible --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

yindo added the pull-request label 2026-06-06 22:09:38 -04:00

yindo closed this issue

2026-06-06 22:09:39 -04:00

yindo referenced this issue

2026-06-06 22:10:03 -04:00

[PR #272] [MERGED] feat: add flow-scoped file uploads #287

yindo referenced this issue

2026-06-06 22:10:09 -04:00

[PR #304] [MERGED] docs(flows): document flow-scoped Files tab, sources, and current limits #310

Sign in to join this conversation.