[PR #268] [CLOSED] feat: queue input for running automation flows #283

New Issue

2026-06-06T22:10:02-04:00

yindo commented

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

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/268
Author: @mason5052
Created: 4/15/2026
Status: ❌ Closed

Base: feature/next-release ← Head: codex/issue-192-automation-queue

📝 Commits (4)

395d02c feat: queue automation input while running
da627b5 fix: harden queued automation stop handling
c17fde4 fix: stop queued input before task registration
2c28818 fix: clarify queued input cancellation

📊 Changes

5 files changed (+630 additions, -57 deletions)

View changed files

📝 backend/pkg/controller/flow.go (+116 -28)
➕ backend/pkg/controller/flow_test.go (+471 -0)
📝 frontend/src/features/flows/flow-form.tsx (+30 -23)
📝 frontend/src/features/flows/messages/flow-automation-messages.tsx (+11 -3)
📝 frontend/src/providers/flow-provider.tsx (+2 -3)

📄 Description

Summary

allow automation flows to accept follow-up input while status is Running
queue submitted input in the backend so it is delivered at the next task boundary instead of requiring an interrupt
keep Stop available in the UI and add queue-focused backend tests

Problem

Issue #192 asks for tighter assistant and automation integration. A smaller but immediately useful part of that request is use case 2: submit new instructions while automation is already running without interrupting the current task.

Today PentAGI blocks that path in two places.

the automation UI hides submit while the flow is Running and only offers Stop
the backend input path uses an unbuffered handoff, so follow-up instructions are not handled as a reliable queue

Solution

Implement the queueing path for running automation flows without expanding scope into assistant handoff or file injection yet.

flow input now uses a bounded FIFO queue with explicit queue-full errors and tests for enqueue, early error, cancel, and stop-drain behavior
provider switching now happens when queued input is actually processed, so queued messages follow the current flow execution path safely
the automation form keeps provider changes disabled, but now allows message submission while Running and shows Stop alongside Submit
queue-focused helper text explains that new instructions are applied at the next task boundary

This intentionally targets use case 2 from #192. Assistant-generated plans, structured handoff, and file or data-source injection can still follow in later work.

User Impact

Users can add follow-up instructions to a running automation flow without interrupting the active task. The current task continues, the new instruction is queued for the next handoff point, and Stop remains available when they do want to cancel execution.

Test Plan

go test ./pkg/controller/...
npx eslint src/features/flows/flow-form.tsx src/features/flows/messages/flow-automation-messages.tsx src/providers/flow-provider.tsx
npm run build
git diff --check

Notes

npm run lint still fails on this Windows host because of pre-existing unrelated frontend lint errors in files such as src/components/shared/markdown.tsx, src/components/ui/textarea.tsx, and several existing flow/search components. The files changed in this PR pass the targeted eslint command above.

_{🔄 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/268 **Author:** [@mason5052](https://github.com/mason5052) **Created:** 4/15/2026 **Status:** ❌ Closed **Base:** `feature/next-release` ← **Head:** `codex/issue-192-automation-queue` --- ### 📝 Commits (4) - [`395d02c`](https://github.com/vxcontrol/pentagi/commit/395d02c04ec3423101625808b088573c48abb042) feat: queue automation input while running - [`da627b5`](https://github.com/vxcontrol/pentagi/commit/da627b5e073e2ba8398c67bcc60b39806c13ec96) fix: harden queued automation stop handling - [`c17fde4`](https://github.com/vxcontrol/pentagi/commit/c17fde435693a60b8cb917a39438b30436fc79c0) fix: stop queued input before task registration - [`2c28818`](https://github.com/vxcontrol/pentagi/commit/2c2881826d8d06e3e9c2566ad05bba6409426a68) fix: clarify queued input cancellation ### 📊 Changes **5 files changed** (+630 additions, -57 deletions) <details> <summary>View changed files</summary> 📝 `backend/pkg/controller/flow.go` (+116 -28) ➕ `backend/pkg/controller/flow_test.go` (+471 -0) 📝 `frontend/src/features/flows/flow-form.tsx` (+30 -23) 📝 `frontend/src/features/flows/messages/flow-automation-messages.tsx` (+11 -3) 📝 `frontend/src/providers/flow-provider.tsx` (+2 -3) </details> ### 📄 Description ## Summary - allow automation flows to accept follow-up input while status is `Running` - queue submitted input in the backend so it is delivered at the next task boundary instead of requiring an interrupt - keep `Stop` available in the UI and add queue-focused backend tests ## Problem Issue #192 asks for tighter assistant and automation integration. A smaller but immediately useful part of that request is use case 2: submit new instructions while automation is already running without interrupting the current task. Today PentAGI blocks that path in two places. - the automation UI hides submit while the flow is `Running` and only offers `Stop` - the backend input path uses an unbuffered handoff, so follow-up instructions are not handled as a reliable queue ## Solution Implement the queueing path for running automation flows without expanding scope into assistant handoff or file injection yet. - flow input now uses a bounded FIFO queue with explicit queue-full errors and tests for enqueue, early error, cancel, and stop-drain behavior - provider switching now happens when queued input is actually processed, so queued messages follow the current flow execution path safely - the automation form keeps provider changes disabled, but now allows message submission while `Running` and shows `Stop` alongside `Submit` - queue-focused helper text explains that new instructions are applied at the next task boundary This intentionally targets use case 2 from #192. Assistant-generated plans, structured handoff, and file or data-source injection can still follow in later work. ## User Impact Users can add follow-up instructions to a running automation flow without interrupting the active task. The current task continues, the new instruction is queued for the next handoff point, and `Stop` remains available when they do want to cancel execution. ## Test Plan - [x] `go test ./pkg/controller/...` - [x] `npx eslint src/features/flows/flow-form.tsx src/features/flows/messages/flow-automation-messages.tsx src/providers/flow-provider.tsx` - [x] `npm run build` - [x] `git diff --check` ## Notes `npm run lint` still fails on this Windows host because of pre-existing unrelated frontend lint errors in files such as `src/components/shared/markdown.tsx`, `src/components/ui/textarea.tsx`, and several existing flow/search components. The files changed in this PR pass the targeted `eslint` command above. --- <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:10:02 -04:00

yindo closed this issue

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

yindo referenced this issue

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

[PR #283] feat: add Telegram bot integration #295

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#283