Scheduler: description field truncates long text #129

Activity

1. Lexus2016 commented on Nov 8, 2026

   

   Lexus2016

   on Nov 8, 2026

   Owner

   More actions

   Thanks, this is accurate. I checked v8.0.2 and every cap you found is there: maxlength="2000" on #fDesc in public/schedule.html:1649 and on six more textareas in public/kanban.html, and String(description).substring(0, 2000) at server.js:6125, 6261, 7624, 7625, 7795 and 13233. The MCP schema at mcp-task-manager.js:45 tells the model the same 2000.

   Two things worth adding. The same 2000 also cuts notes (server.js:7625), not only the description, so a fix has to cover both fields or notes stay capped. And the column is plain description TEXT DEFAULT '' (server.js:729, 880), so nothing has to be migrated: the limit is purely in code and can be raised without touching existing rows.

   What I will change, in this order:

   1. One constant (MAX_TASK_TEXT = 20000) used by the DB writes, the HTTP API, the MCP schema and the client maxlength, so the four places cannot drift apart again.
   2. The server returns a 400 naming the field instead of cutting the text: silent truncation is the part that actually loses work, and a caller that gets its text back unchanged with no error has no way to notice.
   3. A character counter next to the field, and the card clamped to three lines with the full text in the detail view instead of one line.

   An error has one risk you may want to weigh: a caller that today sends 5000 characters through the API would start failing instead of losing 3000 silently. That is the point, but it is a behaviour change, so say if you would rather keep truncating and only warn.
2. Lexus2016

   added 2 commits that reference this issue on Nov 8, 2026

   task text: one 20000-character limit instead of four 2000s (#129)

   ...

   0896dca

   task text: one 20000-character limit instead of four 2000s (#129) (#132)

   ...

   5b9638b
3. Lexus2016

   closed this as completedin #132on Nov 8, 2026
4. Lexus2016 commented on Nov 8, 2026

   

   Lexus2016

   on Nov 8, 2026

   Owner

   More actions

   Shipped in #132, squash 5b9638b.

   • The limit is one number now, MAX_TASK_TEXT = 20000 in task-text-limit.js. server.js uses it in all ten task-text writes, mcp-task-manager.js advertises the same number to the agent, and both pages put it on every description and notes field, so the four places that each carried 2000 cannot drift apart again.
   • The description in the schedule form, and the description and notes in the kanban modal, show a counter (1234 / 20000) that turns red at the limit — a maxlength cut is silent otherwise, and at this size the counter is what tells you where the text stopped.
   • The schedule card shows three lines of a description instead of one.
   • test/task-text-limit.test.js pins all of it, including a real round trip: a 5000-character description now survives the HTTP API, an update and the task-manager endpoint an agent posts to, and 25000 is capped at the limit. On the pre-change tree it fails 18 of 22 checks with expected 5000, got 2000.

   One thing is still open and needs your call, since you raised it: should an over-long request fail with a 400 naming the field, or keep being cut at the limit? I left the truncation in place for now — switching to an error would start rejecting requests that today lose text silently, so it is a behaviour change, not a cleanup. If you would rather have the error, say so and it is a small follow-up: the four write paths and the counter are already the only places that read the value.

   Verified at the merged head: full npm test green on CI for Node 20 and Node 24, and locally on Node 24.22.1 apart from test/task-backlog.test.js, which fails the same way on a clean main here and passes on CI.