[Bug]: Inserts into vecstorelogs and agentlogs fail with "index row size exceeds btree maximum 2704" (same defect fixed in #72, but on sibling indexes)

Affected Component

Other (please specify in the description), Core Services (Frontend UI/Backend API)

Describe the bug

These are the same class of failure already reported and fixed in #72 ("index row size 2744 exceeds btree version 4 maximum 2704 for index subtasks_result_idx"), but on two sibling indexes that were missed by that fix.

The agent/vector-store log rows are silently lost when this happens. Flow results themselves are not affected (the failure is on logging inserts), but internal observability is degraded.

Root cause

Both indexes are plain btree indexes over unbounded TEXT columns, defined in backend/migrations/sql/20241130_183411_new_type_logs.sql:

• line 29: CREATE INDEX agentlogs_task_idx ON agentlogs(task); (task TEXT NOT NULL)
• line 52: CREATE INDEX vecstorelogs_query_idx ON vecstorelogs(query); (query TEXT NOT NULL)

A btree index entry is capped at ~2704 bytes. Agent task descriptions and vector-store queries routinely exceed that, so the insert fails.

This is exactly the same problem as #72. The fix for #72 (backend/migrations/sql/20251028_113516_remove_result_idx.sql) simply dropped the offending indexes:

DROP INDEX IF EXISTS tasks_result_idx;
DROP INDEX IF EXISTS subtasks_result_idx;

…but vecstorelogs_query_idx and agentlogs_task_idx have the same defect and were never touched. There is no later migration that removes or re-shapes them.

Suggested fix

Apply the same remedy used for #72 — a new migration dropping the two text-column btree indexes (they are of little use as exact-match btree indexes on large text anyway):

-- +goose Up
-- +goose StatementBegin
DROP INDEX IF EXISTS vecstorelogs_query_idx;
DROP INDEX IF EXISTS agentlogs_task_idx;
-- +goose StatementEnd

-- +goose Down
-- +goose StatementBegin
CREATE INDEX vecstorelogs_query_idx ON vecstorelogs(query);
CREATE INDEX agentlogs_task_idx ON agentlogs(task);
-- +goose StatementEnd

If exact-match lookups on these columns are ever needed, a hash of the column (as done for toolcalls in 20260720_120000_toolcalls_call_id_hash_idx.sql) would be the safe alternative.

To Reproduce

1. Run any non-trivial flow where the agent produces long task descriptions / vector-store queries (a pentest-style flow triggers it reliably).
2. Watch the Postgres (pgvector) container logs.
3. Observe repeated index row size NNNN exceeds btree version 4 maximum 2704 errors for vecstorelogs_query_idx and agentlogs_task_idx.

Environment

• PentAGI version: 2.2.0-ce (image vxcontrol/pentagi:latest)
• Deployment: docker compose, vxcontrol/pgvector:latest
• Host: Ubuntu Server 26.04, amd64

Additional context

Confirmed against the current main schema. The defective index definitions are still present in backend/migrations/sql/20241130_183411_new_type_logs.sql and no migration removes them. Related prior work: #72 and migrations 20251028_113516_remove_result_idx.sql, 20260720_120000_toolcalls_call_id_hash_idx.sql.

Steps to Reproduce

1. Access PentAGI Web UI and start a new flow (any non-trivial agent flow; a black-box web pentest triggers it reliably).
2. Let the agent run normally — it produces long task descriptions and long vector-store queries.
3. No special target configuration is needed; the bug is in the logging layer, not the target.
4. While the flow runs, watch the Postgres container logs: docker compose logs -f pgvector
5. Error occurs repeatedly: inserts into vecstorelogs and agentlogs fail with index row size NNNN exceeds btree version 4 maximum 2704 for indexes vecstorelogs_query_idx and agentlogs_task_idx. Observed sizes in our run: 2944, 2920 and 3504 bytes. The affected log rows are silently dropped (flow results are not affected).

System Configuration

PentAGI Version: 2.2.0-ce (latest from Docker Hub, image vxcontrol/pentagi:latest) Deployment Type:

• Docker Compose
• Custom Deployment

Environment:

• Docker Version: 29.9.3
• Docker Compose Version: v5.7.0
• Host OS: Ubuntu Server 26.04.1 LTS (x86_64)
• Database image: vxcontrol/pgvector:latest

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