Repository navigation
Conversation
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
There was a problem hiding this comment.
Pull request overview
This PR enables submitting follow-up instructions to an automation flow while it is Running by queueing input server-side and adjusting the UI to allow submission without interrupting the current task.
Changes:
- Backend: switch flow input from an unbuffered handoff to a bounded buffered queue and process provider switches at consumption time.
- Frontend: allow message submission while
Running, keepStopvisible, and add queue-focused helper/placeholder text. - Backend tests: add queue-focused unit tests covering enqueue, full-queue error, early error propagation, cancel, and stop-drain behavior.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| frontend/src/providers/flow-provider.tsx | Removes provider override from automation message submission payload. |
| frontend/src/features/flows/messages/flow-automation-messages.tsx | Enables input submission while Running, keeps Stop available, adds queue messaging. |
| frontend/src/features/flows/flow-form.tsx | Adds props to allow input while loading and show both Submit/Stop buttons as needed. |
| backend/pkg/controller/flow.go | Implements bounded input queueing, stop-time discard/drain handling, and defers provider switching to processing time. |
| backend/pkg/controller/flow_test.go | Adds unit tests for queued input behavior and stop-drain semantics. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
|
@mason5052 thanks again - you've been a consistent and high-quality contributor and this PR is no exception in terms of engineering care. after reviewing the approach carefully I'm going to decline merging it in its current shape, and I want to explain exactly why so the reasoning is clear the core concern: in-memory queue fragility the buffered-channel queue solves the immediate "don't block the caller" problem, but it introduces a class of issues we'd be inheriting permanently:
the task-boundary model creates runaway flows the deeper architectural issue is what happens at the "next task boundary". PentAGI's current model is thank you for tackling this - the problem itself is real and worth solving properly. |
|
@mason5052 I've tried to implement this algorithm here 5067e8f |
|
Thanks for the detailed review and for spelling out the concerns so clearly. I agree the in-memory queue version introduces too much hidden state around persistence, visibility, and flow lifetime, so closing this version makes sense. I also looked through \5067e8f5a44456984f8b3401d47e8aff4722189b, and I think the flow-management-tool direction is much more aligned with PentAGI's task model. I'm happy to treat this PR as superseded and follow up later with tests or docs around that approach if that would be useful. |
- Reword PR vxcontrol#268 references to talk about review feedback rather than the PR being rejected. - Clarify host.docker.internal availability: not universally provided by the core compose stack; Docker Desktop typically resolves it, while Linux/operator-managed compose stacks may need an explicit extra_hosts: host.docker.internal:host-gateway entry or another controlled endpoint. - Make the safe initial Burp example unambiguously read-only: drop start_active_scan from the illustrative allowlist and call out that active capabilities belong to a later, explicitly gated milestone with scope and approval controls. - Rephrase the awkward 'PentAGI must not be inferred...' sentence for clarity. Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Proposes a design direction for native flow concurrency control and completion notifications. The RFC follows the maintainer's relocated proposal pattern at examples/proposals/<topic>.md and explicitly builds on the lessons from PR #268 (rejected because the in-memory queue was hidden lifecycle state). The RFC covers: - Goals limited to capping concurrent flows, persisting queued flows as first-class lifecycle, replacing external polling with at-least- once webhooks, and preserving the existing createFlow contract. - Non-Goals that explicitly forbid hidden in-memory queues, multi- tenant scheduling, generic event bus features, and changing the meaning of 'finished' for tasks/subtasks/toolcalls. - Design Principles for persistence, visibility, manageability, explicit promotion, clear finished semantics, and at-least-once delivery. - A proposed concurrency model with a new persisted 'queued' status, a single MAX_CONCURRENT_FLOWS knob, an explicit promoter, and full UI/API visibility plus user cancellation. - A proposed completion webhook model with per-flow and global URLs, HMAC-SHA256 signatures, persisted deliveries, bounded retries, and SSRF mitigations. - Storage and API surface sketches that do not commit to a final schema. - Open Questions covering per-user limits, blocking semantics on createFlow, signature alignment with the issue #235 receipt direction, and behavior of resources/uploads against queued flows. - A Suggested First Milestone that lands the queue end-to-end before webhooks, to keep PR sizes reviewable. This is documentation only. No runtime code, schema, GraphQL, REST, or UI behavior changes here. Refs #298 Signed-off-by: mason5052 <ehehwnwjs5052@gmail.com>
Add examples/proposals/kubernetes_deployment.md, an RFC-style design surface responding to the Kubernetes deployment request in #324. The document is docs-only: no Helm charts, manifests, operator, compose, installer, or environment-variable changes, and it does not claim Kubernetes is supported today. It records the current Compose/installer deployment assumptions, maps each one (secrets/config, volumes, service discovery, ingress/TLS, health checks, network policies, the Docker-socket flow executor, observability, image overrides, migrations) to candidate Kubernetes equivalents, and proposes an incremental, docs-first path with open questions, security/operational considerations, and a test/validation strategy. The hardest item -- the Docker-socket worker executor -- is laid out as candidate options without choosing one, and keeps flow lifecycle explicit and inspectable per the #268 review lesson. Refs #324
Add examples/proposals/kubernetes_deployment.md, an RFC-style design surface responding to the Kubernetes deployment request in #324. The document is docs-only: no Helm charts, manifests, operator, compose, installer, or environment-variable changes, and it does not claim Kubernetes is supported today. It records the current Compose/installer deployment assumptions, maps each one (secrets/config, volumes, service discovery, ingress/TLS, health checks, network policies, the Docker-socket flow executor, observability, image overrides, migrations) to candidate Kubernetes equivalents, and proposes an incremental, docs-first path with open questions, security/operational considerations, and a test/validation strategy. The hardest item -- the Docker-socket worker executor -- is laid out as candidate options without choosing one, and keeps flow lifecycle explicit and inspectable per the #268 review lesson. Refs #324
Summary
RunningStopavailable in the UI and add queue-focused backend testsProblem
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.
Runningand only offersStopSolution
Implement the queueing path for running automation flows without expanding scope into assistant handoff or file injection yet.
Runningand showsStopalongsideSubmitThis 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
Stopremains 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.tsxnpm run buildgit diff --checkNotes
npm run lintstill fails on this Windows host because of pre-existing unrelated frontend lint errors in files such assrc/components/shared/markdown.tsx,src/components/ui/textarea.tsx, and several existing flow/search components. The files changed in this PR pass the targetedeslintcommand above.