Affected Component
Core Services (Frontend UI/Backend API)
Describe the bug
exa: get https://10.209.46.11:8443/flows/148 maybe wss have bugs
Steps to Reproduce
- get https://10.209.46.11:8443/flows/148
- the page is hanging
System Configuration
docker compose
Logs and Artifacts
No response
Screenshots or Recordings
No response
Verification
- I have checked that this issue hasn't been already reported
- I have provided all relevant configuration files (with sensitive data removed)
- I have included relevant logs and error messages
- I am running the latest version of PentAGI
Activity
3
XinwangTao24d agoThis matches a pattern where the flow-details feed rides on a websocket that silently drops — the page just sits on the loading spinner with no error state. Suggest: (1) frontend timeout on the flow details request with an explicit error/retry UI instead of an infinite spinner, (2) server-side wss heartbeat plus reconnect with exponential backoff, (3) expose the ws://wss:// endpoint in logs so the connection target is checkable when it hangs. Happy to attach capture logs if a repro scenario is defined.
AlaeddineMessadi15d agoThe websocket in your screenshot is healthy: connection_ack arrives and the global subscriptions go out. The flow subscriptions (terminalLogAdded, messageLogAdded, ...) are skipped until the HTTP flow query returns (flow-provider.tsx#L217-L220), and that query is what hung. It loads the flow and all of its logs in one response, with no paging (graphql-schema.graphql#L845-L870).
Up to v2.1.0 nothing limited how long that request could take, so the spinner could stay forever. v2.2.0 adds a 45 s limit in the browser (graphql-deadline.ts#L3), 30 s per GraphQL operation on the server (graphql_deadline.go#L11) and a 25 s Postgres statement_timeout (statement_timeout.go#L11). A failed load now shows "Error loading flow" with a Retry button (flow.tsx#L192-L215).
@laozhudetui could you retest on v2.2.0? If it still fails, please post:
- whether it shows that error (and its text), still spins, or opens with some tabs empty
- the output of
docker compose logs pentagifrom that moment - roughly how many messages and terminal log entries the flow has
This matches a pattern where the flow-details feed rides on a websocket that silently drops — the page just sits on the loading spinner with no error state. Suggest: (1) frontend timeout on the flow details request with an explicit error/retry UI instead of an infinite spinner, (2) server-side wss heartbeat plus reconnect with exponential backoff, (3) expose the ws://wss:// endpoint in logs so the connection target is checkable when it hangs. Happy to attach capture logs if a repro scenario is defined.