fix: remove hardcoded 48-character limit from text inputs

[tomerqodo]

Benchmark PR from agentic-review-benchmarks#5

[claude]

🔴 Bug: Creating a paragraph variable in the pipeline form is broken. The Zod schema at schema.ts:43-47 requires maxLength as a non-optional z.number().min(1).max(TEXT_MAX_LENGTH) for both textInput and paragraph types, but this PR removed the auto-population of maxLength when switching to paragraph (deleted lines 88-89 in hooks.ts) and removed max_length from VAR_ITEM_TEMPLATE_IN_PIPELINE. Since the maxLength UI field is only shown for textInput (not paragraph), users have no way to set it, causing an unrecoverable validation failure when saving. Either restore the auto-set logic for paragraph, make maxLength optional in the schema for paragraph type, or add paragraph to the maxLength field's showConditions.

Extended reasoning...

What the bug is

The pipeline input field editor form uses a Zod schema (schema.ts:43-47) that requires maxLength as z.number().min(1).max(TEXT_MAX_LENGTH) for both textInput and paragraph types. This field is not optional — undefined will fail validation.

How it manifests

Before this PR, two mechanisms ensured maxLength was always populated for paragraph variables:

1. VAR_ITEM_TEMPLATE_IN_PIPELINE in config/index.ts included max_length: DEFAULT_VALUE_MAX_LEN (48), providing a default when creating new variables.
2. handleTypeChange in hooks.ts:88-89 auto-set maxLength to DEFAULT_VALUE_MAX_LEN when the user switched the type to paragraph.

This PR removed both mechanisms. It also only shows the maxLength UI field for textInput — the showConditions at hooks.ts line 131-133 only match PipelineInputVarType.textInput, not paragraph.

Step-by-step proof

1. User opens the pipeline input field editor to create a new variable.
2. The variable is initialized from VAR_ITEM_TEMPLATE_IN_PIPELINE, which no longer includes max_length, so maxLength starts as undefined.
3. User changes the type dropdown to paragraph.
4. handleTypeChange fires but no longer sets maxLength (the auto-set code was deleted).
5. The maxLength form field is hidden because showConditions only matches textInput.
6. User fills in variable name, label, and other fields, then clicks Save.
7. The Zod schema validates: maxLength is undefined, but z.number().min(1).max(256) requires a number → validation fails.
8. The user sees a validation error but cannot fix it because the maxLength field is not visible for paragraph type.

Impact

Creating or editing paragraph-type variables in the rag-pipeline form is completely broken. The form cannot be saved, effectively blocking this functionality.

How to fix

Three possible fixes (pick one):

• Option A: Restore the auto-set logic in handleTypeChange — when type changes to paragraph, set maxLength to a sensible default (e.g., TEXT_MAX_LENGTH or some other value).
• Option B: Make maxLength optional in the Zod schema for paragraph type (e.g., maxLength: z.number().min(1).max(TEXT_MAX_LENGTH).optional()).
• Option C: Add PipelineInputVarType.paragraph to the showConditions for the maxLength field in the configurations, so users can set it manually.

Option A is probably the simplest and most consistent with the original behavior.

[claude]

🔴 Debug console.log("Checking batch inputs:", ...) left in production code at line 199. This logs user batch input data (headers and data length) to the browser console on every batch submission and should be removed before merging.

Extended reasoning...

What the bug is

A console.log statement was added at line 199 of web/app/components/share/text-generation/index.tsx inside the checkBatchInputs function:

console.log("Checking batch inputs:", { dataLength: data.length, headerData })

This is debug logging that was accidentally left in the PR.

Code path that triggers it

The checkBatchInputs function is called by handleRunBatch whenever a user submits a batch of inputs in the shared text generation view. Every single batch submission will trigger this console.log, printing the batch header data (which contains user-defined variable names and potentially sensitive column headers) to the browser console.

Why existing code doesn't prevent it

The project has an ESLint no-console warning rule (referenced in AGENTS.md rule qodo-benchmark#25: "Frontend Code Must Not Use console Statements"), but since it's configured as a warning rather than an error, it doesn't block the build or fail CI. This allowed the statement to slip through.

Impact

In production, this console.log will:

1. Add noise to the browser developer console for every batch submission
2. Log user batch input data (headerData) which could contain sensitive information depending on the application's prompt variables
3. Violate the project's coding standards (AGENTS.md rule [CLEAN] Synthetic Benchmark PR #29179 - chore: update TypeScript type-check command and add native-preview dependency for faster performance dify#25)

While not a crash-level bug, it's unprofessional for production code and represents a minor data exposure concern.

Step-by-step proof

1. User navigates to a shared text generation app and switches to the "batch" tab
2. User uploads a CSV file with batch inputs and clicks Run
3. handleRunBatch is called, which calls checkBatchInputs(data)
4. At line 199, console.log("Checking batch inputs:", { dataLength: data.length, headerData }) executes
5. The browser console displays the batch data length and the full header row from the CSV, which includes all prompt variable names and their values

How to fix

Simply remove line 199:

-    console.log("Checking batch inputs:", { dataLength: data.length, headerData })

[claude]

🔴 The input type for number fields was changed from type="number" to type="text" at line 167, which is unrelated to the PR goal of removing the 48-character limit. This loses browser-native numeric validation (numeric keyboard on mobile, spinner controls, rejection of non-numeric characters), allowing users to enter arbitrary text into numeric fields. The other file handling number inputs (chat-user-input.tsx:113) correctly keeps type="number", confirming this was accidental.

Extended reasoning...

What the bug is

In web/app/components/app/configuration/prompt-value-panel/index.tsx at line 167, the type attribute on the <Input> component for number fields was changed from "number" to "text". This change is bundled with the legitimate maxLength changes but is unrelated to the PR's goal of removing the hardcoded 48-character limit.

How it manifests

When a user configures a prompt variable of type number in the prompt value panel, the input field will now accept any arbitrary text—letters, symbols, special characters—rather than constraining input to numeric values. On mobile devices, users will see a full text keyboard instead of the numeric keypad, and on desktop browsers, the native spinner controls for incrementing/decrementing values will be absent.

The specific code path

The prompt value panel iterates over promptVariables and renders different input types based on the variable's type field. For type === 'number', the code at line 167 renders <Input type="text" ...> instead of <Input type="number" ...>. This means the HTML <input> element loses its type="number" attribute, which is what triggers browser-native numeric validation.

Why existing code doesn't prevent it

There is no JavaScript-level numeric validation on the onChange handler for number inputs—it simply passes e.target.value directly to handleInputValueChange. The code relied entirely on the browser's native type="number" behavior to restrict input to numeric values. With type="text", there is no validation at all.

Inconsistency with other files

The companion file chat-user-input.tsx at line 113 correctly keeps type="number" for the same kind of number input field. This inconsistency strongly suggests the change in prompt-value-panel/index.tsx was accidental. One possible explanation is that the author changed it to make the HTML maxLength attribute work (since maxLength is ignored on type="number" inputs per the HTML spec), but since max_length is typically undefined for number fields after this PR removes defaults, the maxLength prop would be undefined/no-op anyway.

Step-by-step proof

1. A user creates a prompt variable of type number in the app configuration.
2. The prompt value panel renders the input using the code at line 167: <Input type="text" ...>.
3. The user clicks on the number input field and types abc123!@#.
4. Because type="text" accepts any characters, the full string abc123!@# is accepted and stored as the input value.
5. This invalid non-numeric value is then passed downstream when the prompt is executed, potentially causing errors or unexpected behavior.
6. In contrast, the same scenario in chat-user-input.tsx (which keeps type="number") would reject non-numeric characters at the browser level.

How to fix

Revert line 167 from type="text" back to type="number". This restores browser-native numeric validation and maintains consistency with chat-user-input.tsx.

[claude]

🔴 Adding maxLength={max_length} to the paragraph Textarea in chat-user-input.tsx (line 99) introduces a regression for existing paragraph variables. Before this PR, the old config-modal auto-set max_length=48 when switching to paragraph type, but this value was never enforced on paragraph textareas. Now existing paragraph variables with stored max_length: 48 will suddenly be limited to 48 characters — an extremely restrictive limit for a paragraph field. Additionally, prompt-value-panel/index.tsx and run-once/index.tsx do NOT have maxLength on their paragraph Textareas, creating inconsistent enforcement across views.

Extended reasoning...

What the bug is

This PR adds maxLength={max_length} to the paragraph Textarea in chat-user-input.tsx (line 99). Before this PR, the paragraph textarea had no maxLength prop at all. While this change works correctly for new paragraph variables (where max_length is undefined, so maxLength={undefined} means no limit), it creates a regression for existing paragraph variables.

How it manifests — step-by-step proof

1. Before this PR, when a user switched a variable to paragraph type in the config modal, handleTypeChange auto-set max_length = DEFAULT_VALUE_MAX_LEN (48). This value was stored in the backend/variable config.
2. Before this PR, the paragraph Textarea in chat-user-input.tsx had NO maxLength prop, so users could type unlimited text — the stored max_length: 48 was decorative.
3. This PR correctly removes the auto-set of max_length=48 for new paragraph variables (in config-modal/index.tsx), and removes max_length from VAR_ITEM_TEMPLATE (in config/index.ts).
4. However, this PR also adds maxLength={max_length} to the paragraph Textarea in chat-user-input.tsx.
5. For any existing paragraph variable that was created before this PR and has max_length: 48 stored in the database, maxLength={48} is now enforced on the textarea.
6. A 48-character limit on a paragraph field (designed for multi-line, long-form text) is extremely restrictive and breaks the expected user experience.

Inconsistency across views

The enforcement is also inconsistent across the three views that render paragraph textareas:

• chat-user-input.tsx (line 99): Has maxLength={max_length} — newly added by this PR, enforces the limit
• prompt-value-panel/index.tsx (lines 148-153): No maxLength on paragraph Textarea — does NOT enforce the limit
• run-once/index.tsx (lines 146-151): No maxLength on paragraph Textarea — does NOT enforce the limit

This means the same paragraph variable would have a 48-character limit in the chat debug panel but unlimited text in the completion prompt value panel and the shared text-generation form.

Impact

Any existing app with paragraph variables created before this PR will have those variables suddenly limited to 48 characters in the chat debug interface. Users who previously typed long paragraphs will find their input truncated. The PR title says it removes hardcoded limits, but this change paradoxically introduces enforcement that did not exist before.

Suggested fix

Either:

1. Remove maxLength from the paragraph Textarea in chat-user-input.tsx (matching the other two views and the old behavior), or
2. Add maxLength to paragraph textareas in all three views for consistency, AND include a migration or runtime guard to clear stale max_length values (e.g., treat max_length: 48 as undefined for paragraph types).