Increase character limit for AI correction/modifier prompt field in profile settings and database #99
Loading…
Reference in New Issue
Block a user
No description provided.
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?
Summary
The AI correction prompt (and likely the AI modifier prompt) truncates or cuts off when the prompt exceeds a certain character limit. The user reported that a long prompt was posted twice, and both times it was cut off mid-content, including a truncated backtick sequence. The prompt includes extensive rules for markdown optimization, code block preservation, and language handling. The user requests that the character limit be increased tenfold, applied everywhere (validators, database, etc.), with no limits. This issue is related to the comment length issue: if comment length is increased but the correction prompt length is not, long comments will not be corrected properly.
Steps to Reproduce
Expected Behaviour
The prompt should accept and store the full content without truncation, regardless of length. The character limit should be increased tenfold (or removed entirely) in all relevant validators, database fields, and UI components.
Actual Behaviour
The prompt is truncated/cut off when it is long. The user reported that the prompt was posted twice and both times it was cut off mid-content, including a truncated backtick sequence.
Environment
Not provided.
Reported by retoor via DevPlace.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
Starting research round 1 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
Investigated the ticket against the current source and tests. The research confirms a hard 2000-character cap enforced at six distinct locations across four files (Pydantic model, HTML maxlength, and Devii controller slices), matching the ticket’s description of truncation with truncated backticks. The ticket accurately identifies a real bug preventing users from storing long correction/modifier prompts, and all necessary change points are identified with no contradictory findings.
Decision is to proceed. Next step is drafting a concrete implementation plan.
I am drafting the implementation plan now.
The research confirmed the ticket; I am turning the findings into a concrete, verifiable plan.
A draft implementation plan has been completed based on the investigation findings. Six edits across four files are required to increase the prompt field width from 2000 to 20000 characters: two Pydantic fields, two HTML textarea attributes, and two Python controller slices.
The plan includes the exact changes, verification steps using the project's test and lint tools, and a confirmation grep command. The next step is to hand this plan to the execution agent for implementation.
The full, verbatim implementation plan is attached: plan-ticket-99.md
Starting research round 2 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
Investigated the ticket against the current source and tests. The analysis confirms six enforcement points (HTML maxlength, Pydantic schema, Devii controller slices) and two documentation strings independently enforce a 2000‑character limit, while the database already stores prompts as unlimited TEXT.
The research validates the reporter’s request to increase the limit tenfold or remove it entirely as clearly actionable and well‑scoped. No further investigation is required.
Decision: proceed. Next step is drafting a concrete implementation plan.
Starting research round 3 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
I am drafting the implementation plan now.
The research confirmed the ticket; I am turning the findings into a concrete, verifiable plan.
An implementation plan was drafted based on the investigation findings. The plan identifies eight file modifications across six enforcement points and two documentation strings to remove the 2000-character limit on AI correction and modifier prompt fields. The database schema already supports unlimited text and requires no change. Verification steps include grep confirmation of removal, unit tests, linting, and an optional manual smoke test.
The plan is now being handed to the execution agent for implementation.
The full, verbatim implementation plan is attached: plan-ticket-99.md
Starting implementation attempt 1 of at most 5.
I am executing the plan inside this ticket's isolated workspace. This can take a while; I will post periodic progress updates until it completes.
Attempt 1 completed with an inconclusive result. The execution agent's output did not provide a clear indication of success or failure, preventing a definitive assessment.
A second round of targeted research is underway to resolve the ambiguity before another attempt is made.
Starting research round 4 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
The ticket describes character limits on AI correction/modifier prompt fields that should be removed. Commit
c6b87b7already removed those limits across all relevant models, HTML, controllers, and docstrings. The current code reflects a complete fix, so the reported bug no longer exists.Could you confirm whether this is still accurate, or should the ticket be closed?
close it
Posted by retoor via DevPlace.
This ticket has been cancelled and closed at your request. The decision to cancel was made after four research rounds, one execution round, one implementation attempt, and no infrastructure retries. No further action is required.