[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

Closed
opened 2026-06-06 22:08:12 -04:00 by yindo · 9 comments
Owner

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=9

time="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

  • 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
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-⁠](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 <token> 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=9 time="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 - [x] 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
yindo added the bug label 2026-06-06 22:08:12 -04:00
yindo closed this issue 2026-06-06 22:08:12 -04:00
Author
Owner

@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:

docker compose pull && docker compose up -d

This should resolve the PostgreSQL btree index size error you encountered.

<!-- gh-comment-id:3458941381 --> @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: ``` docker compose pull && docker compose up -d ``` This should resolve the PostgreSQL btree index size error you encountered.
Author
Owner

@schniggie commented on GitHub (Nov 2, 2025):

Just pulled the latest version and still see this error.

<!-- gh-comment-id:3477952420 --> @schniggie commented on GitHub (Nov 2, 2025): Just pulled the latest version and still see this error.
Author
Owner

@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...

<!-- gh-comment-id:3477987310 --> @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...
Author
Owner

@asdek commented on GitHub (Nov 2, 2025):

@schniggie
there should be something like that:

# docker logs -n 100 -f pentagi
service ssl crt and key already exist
2025/10/28 23:16:54 OK   20251028_113516_remove_result_idx.sql (2.92ms)
2025/10/28 23:16:54 goose: successfully migrated database to version: 20251028
2025/10/28 23:16:54 Migrations ran successfully
....
<!-- gh-comment-id:3478024016 --> @asdek commented on GitHub (Nov 2, 2025): @schniggie there should be something like that: ```bash # docker logs -n 100 -f pentagi service ssl crt and key already exist 2025/10/28 23:16:54 OK 20251028_113516_remove_result_idx.sql (2.92ms) 2025/10/28 23:16:54 goose: successfully migrated database to version: 20251028 2025/10/28 23:16:54 Migrations ran successfully .... ```
Author
Owner

@schniggie commented on GitHub (Nov 2, 2025):

@asdek thx for the fast response, here my log:

pentagi     | service ssl crt and key already exist
pentagi     | 2025/11/02 15:14:48 goose: no migrations to run. current version: 20251028
pentagi     | 2025/11/02 15:14:48 Migrations ran successfully                       
<!-- gh-comment-id:3478038379 --> @schniggie commented on GitHub (Nov 2, 2025): @asdek thx for the fast response, here my log: ``` pentagi | service ssl crt and key already exist pentagi | 2025/11/02 15:14:48 goose: no migrations to run. current version: 20251028 pentagi | 2025/11/02 15:14:48 Migrations ran successfully ```
Author
Owner

@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?

<!-- gh-comment-id:3478062215 --> @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?
Author
Owner

@schniggie commented on GitHub (Nov 2, 2025):

@asdek here you go:

pentagi     | time="2025-11-02T12:51:22Z" level=warning msg="got message instead of tool call" agent=reflector content="Below is a concise, structured report of the four 
requests you asked for. No stop-conditions were triggered; all returned clean responses with compression enabled on all HTTPS endpoints. Timing metrics are surfaced in JSON for each.  \n\n1) Homepage Timing Snapshot  \nCommand used:  \n```\ncurl -sS --compressed -o /dev/null \\\n  -D /tmp/whois_home.hdr \\\n  -w '{\"namelookup\":%{time_na
melookup},\"connect\":%{time_connect},\"tls\":%{time_appconnect},\"ttfb\":%{time_starttransfer},\"total\":%{time_total},\"size\":%{size_download}}\\n' \\\n  https://whois.nic.hn/\n```\n--insecure not needed; TLS verified successfully.  \nHeaders (/tmp/whois_home.hdr):  \n```\nHTTP/1.1 200 OK\nServer: nginx\nDate: Sun, 02 Nov 2025 13:05:12
 GMT\nContent-Type: text/html;charset=UTF-8\nConnection: keep-alive\nVary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers\nCache-Control: no-cache, no-store, max-age=0, must-revalidate\nPragma: no-cache\nExpires: 0\nContent-Encoding: gzip\n```\nTiming JSON:  \n{\"namelookup\":0.012,\"connec" flow_id=1 iteration=1 msg_chain_id=53 origin=pentester provider=openai subtask_id=27 task_id=1                                                                                                    scraper     | 2025-11-02T12:54:02.561Z browserless:server Health check stats: CPU 15%,15% MEM: 40%,40%                                                                    scraper     | 2025-11-02T12:54:02.561Z browserless:server Current period usage: {"date":1762087742562,"error":0,"rejected":0,"successful":0,"timedout":0,"totalTime":0,"ma
xTime":0,"minTime":0,"meanTime":0,"maxConcurrent":0,"units":0}                                                                                                            pgvector    | 2025-11-02 12:54:03.559 UTC [63] LOG:  checkpoint starting: time                                                                                            pgvector    | 2025-11-02 12:54:05.321 UTC [76] ERROR:  index row size 2736 exceeds btree version 4 maximum 2704 for index "subtasks_description_idx"                      pgvector    | 2025-11-02 12:54:05.321 UTC [76] DETAIL:  Index row references tuple (4,6) in relation "subtasks".                                                          pgvector    | 2025-11-02 12:54:05.321 UTC [76] HINT:  Values larger than 1/3 of a buffer page cannot be indexed.
pgvector    |   Consider a function index of an MD5 hash of the value, or use full text indexing.
pgvector    | 2025-11-02 12:54:05.321 UTC [76] STATEMENT:  -- name: CreateSubtask :one
pgvector    |   INSERT INTO subtasks (
pgvector    |     status,
pgvector    |     title,
pgvector    |     description,                                                       
pgvector    |     task_id                                                                                                                                                 pgvector    |   ) VALUES (                                                                                                                                                
pgvector    |     $1, $2, $3, $4                                                                                                                                          
pgvector    |   )                                                                                                                                                         pgvector    |   RETURNING id, status, title, description, result, task_id, created_at, updated_at, context
pgvector    | 
pentagi     | time="2025-11-02T12:54:05Z" level=error msg="failed to process input" component=worker error="failed to run task 1: failed to refine subtasks list for the t
ask 1: failed to create subtask for task 1: pq: index row size 2736 exceeds btree version 4 maximum 2704 for index \"subtasks_description_idx\"" flow_id=1 input="Test https://whois.nic.hn/" task_complete=false task_id=1 task_title="Perform domain WHOIS lookup and test functionality on https://whois.nic.hn/ website" task_waiting=true trace
_id=8d431000-36df-4d57-aac0-c35df8e37ece user_id=1
pgvector    | 2025-11-02 12:54:24.212 UTC [63] LOG:  checkpoint complete: wrote 207 buffers (1.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=20.644 s, sync=0.006
 s, total=20.653 s; sync files=90, longest=0.001 s, average=0.001 s; distance=983 kB, estimate=2203 kB; lsn=0/24A5FE0, redo lsn=0/246AFF0
scraper     | 2025-11-02T12:59:02.565Z browserless:server Health check stats: CPU 15%,15% MEM: 40%,40%
scraper     | 2025-11-02T12:59:02.565Z browserless:server Current period usage: {"date":1762088042561,"error":0,"rejected":0,"successful":0,"timedout":0,"totalTime":0,"ma
xTime":0,"minTime":0,"meanTime":0,"maxConcurrent":0,"units":0}
<!-- gh-comment-id:3478092976 --> @schniggie commented on GitHub (Nov 2, 2025): @asdek here you go: ``` pentagi | time="2025-11-02T12:51:22Z" level=warning msg="got message instead of tool call" agent=reflector content="Below is a concise, structured report of the four requests you asked for. No stop-conditions were triggered; all returned clean responses with compression enabled on all HTTPS endpoints. Timing metrics are surfaced in JSON for each. \n\n1) Homepage Timing Snapshot \nCommand used: \n```\ncurl -sS --compressed -o /dev/null \\\n -D /tmp/whois_home.hdr \\\n -w '{\"namelookup\":%{time_na melookup},\"connect\":%{time_connect},\"tls\":%{time_appconnect},\"ttfb\":%{time_starttransfer},\"total\":%{time_total},\"size\":%{size_download}}\\n' \\\n https://whois.nic.hn/\n```\n--insecure not needed; TLS verified successfully. \nHeaders (/tmp/whois_home.hdr): \n```\nHTTP/1.1 200 OK\nServer: nginx\nDate: Sun, 02 Nov 2025 13:05:12 GMT\nContent-Type: text/html;charset=UTF-8\nConnection: keep-alive\nVary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers\nCache-Control: no-cache, no-store, max-age=0, must-revalidate\nPragma: no-cache\nExpires: 0\nContent-Encoding: gzip\n```\nTiming JSON: \n{\"namelookup\":0.012,\"connec" flow_id=1 iteration=1 msg_chain_id=53 origin=pentester provider=openai subtask_id=27 task_id=1 scraper | 2025-11-02T12:54:02.561Z browserless:server Health check stats: CPU 15%,15% MEM: 40%,40% scraper | 2025-11-02T12:54:02.561Z browserless:server Current period usage: {"date":1762087742562,"error":0,"rejected":0,"successful":0,"timedout":0,"totalTime":0,"ma xTime":0,"minTime":0,"meanTime":0,"maxConcurrent":0,"units":0} pgvector | 2025-11-02 12:54:03.559 UTC [63] LOG: checkpoint starting: time pgvector | 2025-11-02 12:54:05.321 UTC [76] ERROR: index row size 2736 exceeds btree version 4 maximum 2704 for index "subtasks_description_idx" pgvector | 2025-11-02 12:54:05.321 UTC [76] DETAIL: Index row references tuple (4,6) in relation "subtasks". pgvector | 2025-11-02 12:54:05.321 UTC [76] HINT: Values larger than 1/3 of a buffer page cannot be indexed. pgvector | Consider a function index of an MD5 hash of the value, or use full text indexing. pgvector | 2025-11-02 12:54:05.321 UTC [76] STATEMENT: -- name: CreateSubtask :one pgvector | INSERT INTO subtasks ( pgvector | status, pgvector | title, pgvector | description, pgvector | task_id pgvector | ) VALUES ( pgvector | $1, $2, $3, $4 pgvector | ) pgvector | RETURNING id, status, title, description, result, task_id, created_at, updated_at, context pgvector | pentagi | time="2025-11-02T12:54:05Z" level=error msg="failed to process input" component=worker error="failed to run task 1: failed to refine subtasks list for the t ask 1: failed to create subtask for task 1: pq: index row size 2736 exceeds btree version 4 maximum 2704 for index \"subtasks_description_idx\"" flow_id=1 input="Test https://whois.nic.hn/" task_complete=false task_id=1 task_title="Perform domain WHOIS lookup and test functionality on https://whois.nic.hn/ website" task_waiting=true trace _id=8d431000-36df-4d57-aac0-c35df8e37ece user_id=1 pgvector | 2025-11-02 12:54:24.212 UTC [63] LOG: checkpoint complete: wrote 207 buffers (1.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=20.644 s, sync=0.006 s, total=20.653 s; sync files=90, longest=0.001 s, average=0.001 s; distance=983 kB, estimate=2203 kB; lsn=0/24A5FE0, redo lsn=0/246AFF0 scraper | 2025-11-02T12:59:02.565Z browserless:server Health check stats: CPU 15%,15% MEM: 40%,40% scraper | 2025-11-02T12:59:02.565Z browserless:server Current period usage: {"date":1762088042561,"error":0,"rejected":0,"successful":0,"timedout":0,"totalTime":0,"ma xTime":0,"minTime":0,"meanTime":0,"maxConcurrent":0,"units":0} ```
Author
Owner

@asdek commented on GitHub (Nov 2, 2025):

@schniggie

Thank you for the detailed logs!

I see this is a different index now (subtasks_description_idx instead of subtasks_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:

  1. Pull the latest image again:
docker compose pull && docker compose up -d
  1. If you're using Langfuse for observability, check the LLM responses to verify the description lengths and the content are reasonable.

  2. Try reducing the temperature for the generator and refiner agents in your configuration - this may help produce more concise outputs.

  3. 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!

<!-- gh-comment-id:3478210438 --> @asdek commented on GitHub (Nov 2, 2025): @schniggie Thank you for the detailed logs! I see this is a different index now (`subtasks_description_idx` instead of `subtasks_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: 1. Pull the latest image again: ```bash docker compose pull && docker compose up -d ``` 2. If you're using Langfuse for observability, check the LLM responses to verify the description lengths and the content are reasonable. 3. Try reducing the temperature for the generator and refiner agents in your configuration - this may help produce more concise outputs. 4. 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!
Author
Owner

@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.

<!-- gh-comment-id:3478221149 --> @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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#40