mirror of
https://github.com/vxcontrol/pentagi.git
synced 2026-07-20 12:37:04 -04:00
[GH-ISSUE #72] [Bug]: Not updating Tasks sequentially by failing to update pq: index row size 2744 exceeds btree version 4 maximum 2704 for index \"subtasks_result_idx\" #40
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @adriaanvermaak on GitHub (Oct 28, 2025).
Original GitHub issue: https://github.com/vxcontrol/pentagi/issues/72
Originally assigned to: @asdek on GitHub.
Affected Component
Core Services (Frontend UI/Backend API)
Describe the bug
Hi Team,
quick thank you for the great project.
once a flow starts and what seems to be a common occurrence is that either when a lot of information on agent responses, the flow seems to hang and wait on tasks, and also stop reasoning in the chat interface. you then need to either prompt to commence its subtasks but to find out that it cannot update the working task based on the errors in the logs below.
time="2025-10-27T16:54:56Z" level=error msg="failed to exec tool call" agent=primary_agent error="failed to exec function 'done': reached max retries to call function: failed to execute handler: failed to update subtask 111 result: pq: index row size 2744 exceeds btree version 4 maximum 2704 for index "subtasks_result_idx"" flow_id=11 func_args="{"success":true,"result":"Objective: Detect command injection by targeting endpoints likely to pass user input to OS-level commands. Use time-based payloads and encoding tricks; authenticate where required; provide reproducible evidence.\n\nScope and setup\n- Target: https://juice-shop.herokuapp.com\n- Auth: JWT retrieved via POST /rest/user/login with {\"email\":\"admin@juice-sh.op\",\"password\":\"admin123\"}; used Authorization: Bearer for protected endpoints (token redacted in artifacts).\n- Rate limiting: ≤2 requests/second. Each test gathered a baseline (3 runs) and compared against time-based payloads; delays ≥4s or >3x baseline flagged as suspicious and then validated with multiple sleep durations.\n\nEndpoints and parameters tested\n1) GET /rest/track-order?orderId=\n2) GET /rest/image-captcha?text=\n3) POST /api/Complaints (multipart/form-data: fields message and uploaded file name/metadata)\n4) POST /api/Feedbacks (JSON: comment, rating)\n5) POST /rest/user/change-password (JSON: current, new)\n6) GET /rest/user/data-export (reviewed for params; none observed)\n\nMethodology and payloads\n- Baselines (avg ± stdev over 3 benign requests):\n • /rest/track-order?orderId=1234: 120±15 ms\n • /rest/image-captcha?text=test: 75±10 ms\n • POST /api/Complaints: 210±20 ms\n • POST /api/Feedbacks: 180±25 ms\n- Time-based and filter-evasion payload families attempted (in appropriate contexts):\n • Delimiters: ;, &&, |, ||\n • Exec forms:
sleep 5, $(sleep 5), $(command -v sleep && sleep 5)\n • Space-less variants: ;${IFS}sleep${IFS}5;, $IFS$9 substitutions, tabs, $'\\x20'\n • Encodings: URL-encoded (%3Bsleep%205%3B), double-encoded, Unicode escapes, mixed-case (SlEeP)\n • JSON and multipart injections embedded in string fields and filenames; tried trailing comment markers (#, %23) where applicable.\n- Validation: If delay suspected, re-tested with 3s and 6s sleeps to observe proportionality.\n\nKey results by endpoint\n- /rest/track-order?orderId=\n • Example: orderId=1234;sleep 5;\n • Variants: backticks, $(), ${IFS}, URL-encoded forms.\n • Result: Response times ~baseline (≈125 ms). No proportional delays observed.\n\n- /rest/image-captcha?text=\n • Example: text=test;${IFS}sleep${IFS}5;\n • Variants: ; sleep 5;,sleep 5, $(sleep 5), encoded versions.\n • Result: ~80 ms; no timing anomalies.\n\n- POST /api/Complaints (multipart)\n • message=\"Complaint; sleep 5;\"\n • filename=\"test; sleep 5;.txt\"\n • Result: ~220 ms; filenames sanitized/normalized; no timing anomalies.\n\n- POST /api/Feedbacks (JSON)\n • {\"comment\":\"Nice app; sleep 5;\",\"rating\":5}\n • Result: ~185 ms; no delay.\n\n- POST /rest/user/change-password (JSON)\n • Payloads with delimiters and sleep attempts embedded in string values.\n • Result: No delay; consistent 2xx/4xx responses per normal behavior.\n\n- GET /rest/user/data-export\n • No injectable parameters identified; invoked directly for baseline; no anomalies.\n\nOverall conclusion\n- No command injection vulnerabilities were detected across tested parameters. All inputs appear to be treated as data, not passed to shell/system utilities. Time-based payloads produced no measurable delays beyond baseline jitter, and no linear correlation with varied sleep durations was observed.\n\nEvidence and artifacts\n- Collected requests, response codes/sizes, timing measurements, and payload matrices stored under: /work/tmp/cmdinj/\n • timings_track-order.log\n • requests_image-captcha.log\n • complaints_multipart_tests.log\n • feedbacks_json_tests.log\n • change_password_tests.log\n- JWTs and sensitive tokens are redacted in shared artifacts.\n\nBlockers and considerations\n- None critical. Network jitter was low and consistent; no WAF-like behavior or throttling beyond normal rate limiting observed.\n- Some endpoints return verbose 500s elsewhere in the app, but not relevant here; still noted as info disclosure in broader assessment.\n\nRecommendations\n- Maintain current practice of avoiding shell invocation on user-controlled input; prefer safe library calls.\n- If any server-side utilities are introduced in future features (e.g., image processing, archiving), ensure:\n • Strict input validation/allow-lists\n • No shell concatenation; use parameterized library APIs\n • Drop privileges and sandbox subprocesses where unavoidable\n- Add regression tests for the tested parameters to catch future command injection regressions.\n\nRisk rating for command injection: No findings (informational only).","message":"Command injection testing completed: no vulnerable parameters found. Evidence saved under /work/tmp/cmdinj/."}" func_name=done msg_chain_id=316 provider=openai subtask_id=111 task_id=9time="2025-10-27T16:54:56Z" level=error msg="failed to perform primary agent chain" error="failed to exec function 'done': reached max retries to call function: failed to execute handler: failed to update subtask 111 result: pq: index row size 2744 exceeds btree version 4 maximum 2704 for index "subtasks_result_idx""
time="2025-10-27T16:54:56Z" level=error msg="failed to process input" component=worker error="failed to run task 9: failed to perform agent chain for subtask 111: failed to perform primary agent chain: failed to exec function 'done': reached max retries to call function: failed to execute handler: failed to update subtask 111 result: pq: index row size 2744 exceeds btree version 4 maximum 2704 for index "subtasks_result_idx"" flow_id=11 input="Please mark subtask 109 as complete then proceed with remaining subtasks and finish the assessment, including the final report." task_complete=false task_id=9 task_title="Comprehensive Vulnerability Assessment of Juice-Shop Web Application Including Endpoint Mapping, Path Traversal, CSRF, XSS, SQLi, Command Injection, SSRF, XXE, and Unsafe File Uploads" task_waiting=true trace_id=32d9cbb3-4cc1-4650-af9c-3fef150c4568 user_id=1
Steps to Reproduce
as mentioned above
System Configuration
latest version from dockerhub
Logs and Artifacts
No response
Screenshots or Recordings
No response
Verification
@asdek commented on GitHub (Oct 28, 2025):
Hello @adriaanvermaak,
Thank you for reporting this issue!
This problem has been fixed in the latest version. You can update by running:
This should resolve the PostgreSQL btree index size error you encountered.
@schniggie commented on GitHub (Nov 2, 2025):
Just pulled the latest version and still see this error.
@asdek commented on GitHub (Nov 2, 2025):
Hello @schniggie
Could you show log lines after restart pentagi container?
There should be line which show the latest version after migration, maybe this version isn't fully apply...
@asdek commented on GitHub (Nov 2, 2025):
@schniggie
there should be something like that:
@schniggie commented on GitHub (Nov 2, 2025):
@asdek thx for the fast response, here my log:
@asdek commented on GitHub (Nov 2, 2025):
So good so far, maybe do you have some different error because the index from your first error line was removed from this migration.
Could you share new error line?
@schniggie commented on GitHub (Nov 2, 2025):
@asdek here you go:
@asdek commented on GitHub (Nov 2, 2025):
@schniggie
Thank you for the detailed logs!
I see this is a different index now (
subtasks_description_idxinstead ofsubtasks_result_idx). This is quite unusual - it appears the LLM is generating extremely long descriptions for subtasks that exceed PostgreSQL's btree index limit.Could you please share which LLM provider and model you're currently using? This will help us understand the behavior better.
By the way, I removed this index as well, please try the following:
If you're using Langfuse for observability, check the LLM responses to verify the description lengths and the content are reasonable.
Try reducing the temperature for the generator and refiner agents in your configuration - this may help produce more concise outputs.
Check if there are any
</think>tags appearing in the description or other fields - this could indicate an issue with reasoning content splitting where thinking blocks aren't being properly separated from the main content.Thank you for your feedback!
@schniggie commented on GitHub (Nov 2, 2025):
@asdek Thanks will try the updated image and also add langfuse, haven't used any observability here yet, just started my first tries today. And the above error was produced by OpenAI with the default model configs, haven't changed anything.