The Value Is Too Short. Why Does checkValidity() Pass?

When a form field has minlength=5 but its value is set via script to "abc", it may surprisingly still pass native validation. For example, an imported record populates an input with value abc (length 3) for a required field that a user interface normally enforces as at least 5 characters. Intuition says the field is too short, but input.checkValidity() returns true. This is not a browser bug, but a consequence of how HTML form constraints work: the minlength rule only applies to user-edited values, not programmatic ones.

In this article we walk through a nine-case qualification protocol (seven automatic cases plus two manual user-typing cases) that records the raw validity state of each situation along with an application-level policy result. The harness (described below) snapshots input.value, input.validity.tooShort, input.validity.customError, input.checkValidity(), and our own policy flag for each case. We do not run the harness in an actual browser during this write-up; instead we document the expected behavior and how to capture evidence in practice. The goal is to explain why a script-populated value bypasses the native minlength constraint, and then to enforce a consistent length rule by owning the validation with setCustomValidity.

1. Declare which values the application may admit

First, establish the application’s length requirement as part of the data contract. In our example, every required text field must have at least 5 UTF-16 code units (roughly characters) of content; optional fields may be empty. (This contract is separate from the native HTML minlength attribute, which as we’ll see behaves differently.) Recording the admission policy explicitly is crucial. As Refonte’s FormData testing guide explains, start with the declared contract rather than what a reviewer merely sees on screen. In practice, list each field’s intended minlength, whether it’s required or not, and how repeated fields or defaults should behave. For example, our policy function is simply: empty is only allowed if not required; otherwise value.length >= 5.

By contrast, the browser’s own validity state has its own internal rules. We will keep the application policy (what the backend or business logic expects) separate from the native boolean validation result (checkValidity()). During testing, both are recorded. This distinction prevents confusion between “the input looks filled” and “the input satisfies the formal contract,” much like auditing native form entries rather than relying on visible content. In the harness below, each case yields both a native check and our policy flag.

2. Read the complete tooShort condition

The HTML specification is explicit: an input is flagged tooShort only if all of these are true: it has a minlength constraint, its dirty value flag is true, and its value was last changed by the user (not a script), and the value is not empty, and value.length < minlength. In other words, simply having a short value is not enough; it must result from an actual user edit. The spec (WHATWG) algorithm states:

“If an element has a minimum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), its value is not the empty string, and the length of the element’s API value is less than the element’s minimum allowed value length, then the element is suffering from being too short.”

A programmatically assigned value does not trigger tooShort merely because it is short: assigning input.value sets the dirty value flag to true, but the last change is still a script change. An unchanged initial value also does not meet the complete tooShort condition. Also note: the length is measured in UTF-16 code units (for ASCII text, that’s just the number of characters). The MDN minlength reference explains that this minimum-length constraint applies to user-edited values. Other constraints can still fail after a script assignment, as the required-empty control demonstrates. Therefore, when a script writes a short string into the field, the native tooShort test is skipped and checkValidity() remains true (assuming no other errors).

Dirty state does not identify the last editing route

The dirty value flag is internal state, not a detector of which route last changed the value. It starts false and can become true through either a user edit or an assignment to input.value. When it is false, the value follows the default value; setting it true separates the current value from later default-value changes. A later script assignment therefore leaves the flag true while making the last value change programmatic. Calling dispatchEvent(new Event("input")) after setting .value does not simulate a user edit. The MDN event-trust reference explains that dispatched events have isTrusted = false; dispatching such an event does not turn the assignment into a user edit. The harness records each manual control’s input events and checks the final recorded event, together with the current value, as evidence supporting the operator’s physical-typing procedure. These checks do not independently prove physical keyboard use or exclude every intervening script assignment.

3. Freeze the environment and expected matrix

Before running any tests, define a controlled HTML fixture. Use a fresh HTML page, no frameworks or autofill, and record the exact browser and OS version in use. The lab has an environment field and a start button. It creates fresh type="text" test controls with minlength="5", runs and removes each automatic control, and then displays two manual controls with one capture button each (see Section 4). All fields are enabled. Ensure the input’s willValidate is true by default (it is for text inputs). By isolating the scenario, we eliminate confounders like IME input, third-party scripts, or alternate input types.

For clarity on length counting, remember that JavaScript’s string.length counts UTF-16 code units. Since our examples use only basic ASCII letters, each character is one code unit. (If we needed to handle Unicode astral symbols, they would count as two code units each, but that’s out of scope here.) We explicitly choose ASCII test values to avoid grapheme vs. code unit issues; in other words, “five characters” indeed means length >= 5.

We also record the oracle: the exact expected validity-state tuple for each case. The harness defines an array EXPECTED listing each case’s [value, willValidate, tooShort, valueMissing, customError, checkValidity, applicationPolicy]. For example, under the minimum-length rule, a required field initialized through its value attribute or assigned "abc" by script is expected to have tooShort=false, valueMissing=false, checkValidity=true, and our applicationPolicy=false (since 3 < 5 under the UTF-16 length definition). All expectations come from the specification and policy; we will compare them to the observed snapshots. Any mismatch means a FAIL. Never rely on a running ValidityState object; we copy scalar values into a JSON report for each run (so the check is a literal comparison).

Keep code units separate from product language

To be precise: the minlength length measurement uses the string’s length in UTF-16 code units. We do not treat “character” as user grapheme; this is a code-unit count. This matches JavaScript string length: for example, "\u{1F680}".length === 2, so a qualifying user-edited value containing that one rocket satisfies minlength="2". Our tests use only basic letters (A–Z), so each glyph is one code unit. Any deeper Unicode normalization or grapheme logic would be a separate engineering task, not assumed here.

4. Build the standalone qualification harness

Save and open the following as a local HTML file. It defines the test fixture with manual steps described by the operator. All code below must run together. The script sets up seven automated cases and two manual-capture cases. It records each input’s snapshot (value, validity flags, checkValidity result, application policy) and outputs a JSON report with each case’s status. The operator must enter the exact environment string (browser and OS version) before starting.

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<title>Minimum-length provenance laboratory</title>
<h1>Minimum-length provenance laboratory</h1>
<p>Record the exact browser build and operating system before starting. 
Use a fresh run for each environment. No form is submitted.</p>
<label>Environment <input id="environment" type="text"></label>
<button id="start" type="button">Start fresh run</button>
<p id="instructions"></p>
<div id="controls"></div>
<pre id="evidence"></pre>
<script>
"use strict";
const fields = ["value", "willValidate", "tooShort", "valueMissing",
  "customError", "checkValidity", "applicationPolicy"];
const EXPECTED = {
  "markup-short": [["abc", true, false, false, false, true, false]],
  "script-short": [["abc", true, false, false, false, true, false]],
  "user-short": [["abc", true, true, false, false, false, false]],
  "user-then-script": [["abcd", true, false, false, false, true, false]],
  "script-plus-synthetic-input":
    [["abc", true, false, false, false, true, false]],
  "required-empty": [["", true, false, true, false, false, false]],
  "optional-empty": [["", true, false, false, false, true, true]],
  "bridged-import": [["abc", true, false, false, true, false, false]],
  "stale-custom-error-then-repair": [
    ["abcde", true, false, false, true, false, true],
    ["abcde", true, false, false, false, true, true]]
};
const host = document.getElementById("controls");
const output = document.getElementById("evidence");
const instructions = document.getElementById("instructions");
let report = {status: "NOT_STARTED"};
let sequence = 0;
function require(condition, message) {
  if (!condition) throw new Error(message);
}
function equal(a, b) {
  return JSON.stringify(a) === JSON.stringify(b);
}
function render() {
  if (report.cases) {
    const rows = Object.values(report.cases);
    report.status = report.fatal || rows.some(r => r.status === "FAIL")
      ? "FAIL" : rows.every(r => r.status === "PASS")
      ? "PASS_NINE_CASES" : "HOLD_NOT_EXECUTED";
    report.pending = rows.filter(r => r.status === "PENDING").map(r => r.id);
  }
  output.textContent = JSON.stringify(report, null, 2);
}
function make(id, required = true, attributeValue = null) {
  const wrap = document.createElement("p");
  const label = document.createElement("label");
  const input = document.createElement("input");
  input.type = "text";
  input.id = id;
  input.minLength = 5;
  input.required = required;
  if (attributeValue !== null) input.setAttribute("value", attributeValue);
  label.append(document.createTextNode(id + " "), input);
  wrap.append(label);
  host.append(wrap);
  return {input, wrap};
}
function policy(input) {
  return input.value === "" ? !input.required : input.value.length >= 5;
}
function synchronize(input) {
  input.setCustomValidity(input.value !== "" && input.value.length < 5
    ? "Minimum length is 5 for this fixture." : "");
}
function snapshot(input) {
  const checked = input.checkValidity();
  return [input.value, input.willValidate, input.validity.tooShort,
    input.validity.valueMissing, input.validity.customError,
    checked, policy(input)];
}
function runCase(id, operation) {
  const row = {id, status: "FAIL", expected: EXPECTED[id], observed: []};
  report.cases[id] = row;
  try {
    operation(row);
    require(equal(row.observed, EXPECTED[id]), "Validity tuple mismatch");
    row.status = "PASS";
  } catch (error) {
    row.error = {name: error.name, message: error.message};
  } finally {
    row.finishedAt = new Date().toISOString();
    render();
  }
}
function automatic(id, operation, required = true, attributeValue = null) {
  runCase(id, row => {
    const control = make(id, required, attributeValue);
    try { operation(control.input, row); }
    finally { control.wrap.remove(); }
  });
}
function manual(id, typedValue, rewrite) {
  const control = make(id);
  const events = [];
  const recordInput = event => events.push({
    isTrusted: event.isTrusted, value: control.input.value
  });
  control.input.addEventListener("input", recordInput);
  const button = document.createElement("button");
  button.type = "button";
  button.textContent = "I typed " + typedValue + "; capture " + id;
  control.wrap.append(button);
  button.addEventListener("click", () => {
    runCase(id, row => {
      row.inputEvents = events.slice();
      row.operatorProtocol = "Physical keyboard editing, then capture button";
      require(control.input.value === typedValue, "Wrong typed value");
      require(events.length > 0 && events[events.length - 1].isTrusted,
        "Missing user-agent editing evidence; do not substitute dispatchEvent");
      if (rewrite) {
        row.typedBaseline = snapshot(control.input);
        require(equal(row.typedBaseline,
          ["abcde", true, false, false, false, true, true]),
          "Typed baseline mismatch");
        control.input.value = "abcd";
      }
      row.observed.push(snapshot(control.input));
    });
    button.disabled = true;
    control.input.removeEventListener("input", recordInput);
    control.wrap.remove();
  }, {once: true});
}
document.getElementById("start").addEventListener("click", () => {
  host.replaceChildren();
  report = {
    fixture: "minlength-provenance-v1",
    runId: Date.now() + "-" + (++sequence) + "-" + Math.random().toString(36).slice(2),
    startedAt: new Date().toISOString(),
    environment: document.getElementById("environment").value.trim(),
    userAgent: navigator.userAgent, fields,
    status: "FAIL", cases: {}
  };
  for (const id of Object.keys(EXPECTED)) {
    report.cases[id] = {id, status: "PENDING"};
  }
  try {
    require(report.environment.length > 0, "Enter exact browser and OS versions");
    automatic("markup-short", (input, row) => {
      row.observed.push(snapshot(input));
    }, true, "abc");
    automatic("script-short", (input, row) => {
      input.value = "abc"; row.observed.push(snapshot(input));
    });
    automatic("script-plus-synthetic-input", (input, row) => {
      const events = [];
      const listener = event => events.push(event.isTrusted);
      input.addEventListener("input", listener);
      try {
        input.value = "abc";
        input.dispatchEvent(new Event("input", {bubbles: true}));
        row.eventTrust = events;
        require(equal(events, [false]), "Synthetic-event control mismatch");
        row.observed.push(snapshot(input));
      } finally { input.removeEventListener("input", listener); }
    });
    automatic("required-empty", (input, row) => {
      input.value = ""; row.observed.push(snapshot(input));
    });
    automatic("optional-empty", (input, row) => {
      input.value = ""; row.observed.push(snapshot(input));
    }, false);
    automatic("bridged-import", (input, row) => {
      input.value = "abc"; synchronize(input);
      row.observed.push(snapshot(input));
    });
    automatic("stale-custom-error-then-repair", (input, row) => {
      input.value = "abc"; synchronize(input);
      input.value = "abcde";
      row.observed.push(snapshot(input));
      synchronize(input);
      row.observed.push(snapshot(input));
    });
    manual("user-short", "abc", false);
    manual("user-then-script", "abcde", true);
    instructions.textContent = "Physically type abc in user-short and abcde in " +
      "user-then-script. Capture each with its button. Preserve the JSON before " +
      "starting again. Pending or failed cases do not qualify this environment.";
  } catch (error) {
    report.fatal = {name: error.name, message: error.message};
  } finally { render(); }
});
render();
</script>
</html>

Harness procedure: After saving and opening this file in your browser, type in the Environment field (e.g. “Chrome 116.0 on macOS 13.6”), then click Start fresh run. The script will automatically create controls and run most cases. For the user-short and user-then-script cases, follow the on-screen instructions: physically type the indicated string ("abc" or "abcde") into the newly created field and click the corresponding capture button. Do not use any automated .value assignment or dispatched events. The harness records every input event it receives for each manual control and requires the final recorded event to have isTrusted=true, as well as requiring the exact instructed value. Once complete, the <pre> will contain the full JSON report. (Important: if you restart the run, be sure to save the JSON first, as a fresh run will overwrite it.) No form is actually submitted; this is a passive validation lab.

5. Compare markup and script with actual editing

The first three cases illustrate how the same text can have different validity outcomes. In markup-short, the harness creates a fresh input and sets its value content attribute to "abc" before any user editing or .value assignment. This exercises the initial-value route represented by <input value="abc" minlength="5" required>. In script-short, the HTML had no initial value but the script immediately set input.value = "abc". In both cases, no user interaction occurred. Both cases are expected to yield tooShort=false and input.checkValidity() = true, even though "abc" is under length, because neither was a user edit. By contrast, in user-short, the user types "abc" manually (with the browser’s dirty flag set); the oracle expects tooShort=true and checkValidity=false, as the spec prescribes.

The expected comparison is that the identical three-character string is natively valid when script-assigned and invalid after the prescribed user edit. For script-short, the oracle expects tooShort=false and checkValidity=true; for user-short, it expects tooShort=true and checkValidity=false. These are expectations to compare with a completed browser report, not supplied observations. In every required case containing "abc", the application policy is false because the value has fewer than five code units. The markup and script controls deliberately expect disagreement between native validity and application policy; the user control expects both checks to reject the value.

Preserve the real-edit control

Follow the stated manual procedure: physically type into the fresh controls, then use their capture buttons. The script-plus-synthetic-input case is a separate negative control; it does not substitute for either manual case. For the manual controls, the harness requires the exact instructed value and a trusted final recorded input event. Those checks support the procedure but do not prove that every change came from physical typing. A script assignment after an earlier trusted event is not categorically excluded by these checks. Preserve the operator protocol and recorded event evidence when reviewing the result.

6. Show why a later script write changes the comparison

The user-then-script case tests a mixed scenario. The user first types "abcde" (5 characters) into a newly created field. This initial user edit is expected to yield tooShort=false and checkValidity=true. The harness even records a “typed baseline” snapshot of this valid input to confirm expected behavior. Then, still in code, the script overwrites that value with "abcd" (4 characters). Notice: the dirty flag remains true because the field was touched, but the last change now came from a script, not the user. According to the spec, the "abcd" is treated just like our earlier script-short case: since the user was not the last changer, it does not trigger tooShort. The expected final state is tooShort=false and checkValidity=true even though 4 < 5.

This comparison emphasizes that tooShort depends on the last value change being a user edit, together with its other specified conditions. Once a user finishes typing, the field cannot be assumed to retain user-edit provenance if a script later modifies it. After the script overwrite, the oracle expects native validation to accept "abcd" while the application policy rejects it. The application therefore still needs to enforce its own length policy.

7. Reject the synthetic-event shortcut

Some might think “what if we fire an input event after changing .value?” That is precisely what script-plus-synthetic-input does: it sets input.value="abc" and then calls input.dispatchEvent(new Event("input")). The harness listens to the event and records that isTrusted=false for it (since it was dispatched). The expected result is the same as script-short: tooShort=false and checkValidity=true. Dispatching an event does not convert the assignment into a user edit. In other words, programmatically “notifying” listeners does not satisfy the spec’s requirement of a genuine user change. The browser never internally marks the field as user-edited in that way. Thus, re-running checkValidity() after a synthetic event is expected to pass (and indeed our expected tuple for that case matches script-short exactly).

Separate a notification from an edit

The distinction is conceptual: calling dispatchEvent only runs event handlers after the value is already set. It does not engage the native editing logic. In effect, the code notifies any listeners (for our logging) but does not replicate typing on the keyboard. The HTML spec’s constraint validation algorithm does not care about events; it looks at the internal state flags. As MDN notes, an event from dispatchEvent is marked untrusted, indicating it is not equivalent to a user action. An event notification does not itself establish the user-edit condition required by the minimum-length rule. Use the prescribed physical typing for this laboratory’s two manual controls.

8. Use required and optional emptiness as controls

The required-empty and optional-empty cases show another important behavior: emptiness. If the field is required and left empty (either initially or by script), validityState.valueMissing becomes true and checkValidity() fails. For an optional field (required=false), an empty value is allowed even with minlength set. The harness expects required-empty to have valueMissing=true and checkValidity=false, while optional-empty has all validity-error flags false and checkValidity=true. These controls test that minlength alone does not forbid empty strings unless required is also present. These cases guard against the false belief that any script assignment bypasses all validation. They remind us that the browser still enforces the empty-vs-filled rule: optional fields can be blank, required fields cannot. The length contract remains in effect only for nonempty values.

9. Bridge the application rule into custom validity

Since short values from scripts slip past native checks, we must enforce the application rule ourselves. The solution is to invoke the constraint validation API at the “admission boundary.” In the bridged-import automatic case, after setting input.value = "abc", we call synchronize(input), which does:

input.setCustomValidity(input.value !== "" && input.value.length < 5
  ? "Minimum length is 5 for this fixture." : "");

This sets a custom error on the input whenever the (nonempty) value is too short by our policy. The browser then treats the field as invalid (input.validity.customError = true) regardless of tooShort. Importantly, we do not use minlength for these checks after script imports; we use our own. This means we do not bypass or replicate the native constraint; we merely add our own message. If a user later fixes the value, we clear the custom message so that normal validation resumes. The key is coordination: our validator runs on imports (and potentially on input events) to supplement, not replace, the built-in flags.

A custom error can coexist with tooShort being false

In bridged-import, the oracle specifies exactly that scenario. The value is "abc" (nonempty and short). Native tooShort is false (since it was a script change), but setCustomValidity installs a message that makes input.validity.customError true. The expected snapshot is [ "abc", true, false, false, true, false, false ]: tooShort=false but customError=true and checkValidity=false. This shows that having a custom error does not force tooShort to true; they are independent flags. One reports the built-in rule, the other carries our own message. Both contribute to checkValidity() failing when either is true. This allows us to communicate to the user (and testing evidence) that “length 5 required” even if the browser’s tooShort logic didn’t catch it.

10. Recover from the stale custom error

The stale-custom-error-then-repair case has two snapshots, demonstrating how to clear the custom error. Initially, the script sets the short value "abc" and sets a custom message. Then it assigns "abcde" (5 characters). At this point, "abcde" meets the length policy, but the old custom error is still present from the first assignment. The first expected snapshot is [ "abcde", true, false, false, true, false, true ]: note that customError=true and checkValidity=false, even though tooShort=false and policy is now true. We must remove the obsolete error. The harness then calls synchronize(input) again, clearing the error. The second expected snapshot shows [ "abcde", true, false, false, false, true, true ]: the three recorded validity-error flags are false, while willValidate, checkValidity, and applicationPolicy are true. After synchronization clears the stale message, the script-assigned value is expected to pass both native validation and the application policy.

This illustrates the repair step: after the user (or code) corrects the value to meet policy, call input.setCustomValidity("") to clear the message. Until we do, the field stays blocked by customError. In practice, a form’s change or input handler might run this helper whenever the value length becomes sufficient. After clearing, the field’s validityState.tooShort may still be false (and indeed it is), but that’s fine because the value is long enough. Note that clearing the custom error does not affect unrelated constraints (like required): empty is still treated by valueMissing, etc.

11. Reconcile every case before accepting the harness

We now have the oracle: the exact expected tuple for each test case. The harness compares row.observed, an array of snapshot tuples, with EXPECTED[id]. Each snapshot has seven scalar values. Most cases contain one snapshot; stale-custom-error-then-repair contains two. Every entry must match exactly. For clarity, the expected outcomes are:

These values come straight from the EXPECTED map. The table omits willValidate, which is expected to be true in every snapshot. The two stale-error rows belong to one case, so ten displayed snapshots represent nine cases. After running all cases, the harness sets report.status = "PASS_NINE_CASES" only if all rows reach "PASS". In our notation, rows with "PASS" have observed equal to EXPECTED. A case-level mismatch or exception produces a FAIL row. A fatal setup error is recorded in report.fatal and makes the overall report FAIL, even if some case rows remain PENDING.

In a real test, the two manual cases start as "PENDING" until the user finishes them. If all seven automatic cases pass, the report remains HOLD_NOT_EXECUTED until both manual cases also pass. Any failed case or fatal setup error makes the report FAIL. PASS_NINE_CASES requires all nine case rows to pass. We do not simply count how many inputs were valid; we ensure each field’s flags match exactly what the spec and policy dictate. This replicability is the essence of evidence: each element of each snapshot is a datum in our test report.

12. Define the browser qualification decision

Interpret the report as a qualification of this fixture’s expected browser behavior, then assess whether the application’s actual admission paths enforce its declared policy. The resulting decision is ACCEPT, REPAIR, or HOLD, according to the evidence available:

Native minlength alone does not enforce this application policy for the script-assigned values in the fixture. An application path that depends on that assumption needs REPAIR through a consistently applied policy check. No completed browser run is supplied here, so the browser qualification remains HOLD. The related FormData testing guide makes the same distinction between a designed laboratory and completed browser evidence. A completed PASS_NINE_CASES report would establish that this fixture behaved as expected in the recorded environment, including its intentional negative controls and custom-validity repair. Application acceptance also requires evidence that the relevant import and admission paths invoke the helper correctly. Without that evidence, deployment acceptance remains on HOLD.

Keep missing execution visible

Completing the seven automatic cases alone does not produce PASS_NINE_CASES: when both manual rows remain pending and no failure has occurred, the report is HOLD_NOT_EXECUTED. Complete the physical-typing controls for "abc" and "abcde" and retain their evidence. An unresolved failed or missing case prevents acceptance of the qualification. Only when all snapshots are recorded and report.status = PASS_NINE_CASES has the complete fixture matched its expected specification and policy matrix.

13. Assign ownership at import and admission boundaries

Finally, break down who is responsible for each part of this workflow. The frontend developer (component owner) is responsible for any code that sets input values (the import or adapter code) and for invoking setCustomValidity appropriately. The product owner or API team owns the length policy (e.g. that minlength = 5 is the business rule) and ensures it is communicated to all teams. The QA/automation engineers own the test harness and regression suite (as described in Refonte’s guide to QA automation responsibilities and reproducible checks). They ensure that when code or requirements change, we rerun these exact nine cases.

Triggers for regression runs include any changes to:

• the import adapter or data source,

• the input field’s attributes (required or minlength),

• custom validators or synchronization code,

• the runtime or browser updates (in case validity algorithms change),

• or component wrappers that might override event handling.

If a developer inadvertently regresses (for example, by removing the custom-validity logic), rollback to the known-working version is warranted, or quickly patch the logic back. Historical data already accepted by the flawed logic requires a separate review (outside this automated fix), because we don’t retroactively “fix” user records; we only fix the live admission check. Throughout this, keep backend validation responsibilities clear: the frontend check guards UX, but final enforcement (e.g. double-check in an API) remains recommended.

14. Build the frontend foundations behind reliable admission

Ensuring robust form validation is part of broader frontend engineering practice. Modern front-end development blends creativity with engineering to meet high UX expectations. Refonte Learning’s Frontend Development program (approximately 10–12 hours/week) covers these foundations (HTML5/CSS3, JavaScript ES6+, React/Redux, Web APIs, responsive design, Git, and more) through practical projects. Graduates earn a Training Certificate and a Certificate of Internship (though placements aren’t guaranteed) after learning best practices in building and debugging web interfaces.

The next step for your team is: preserve the detailed test ledger from this harness and actually run the missing manual cases. Only with that concrete evidence of each input path can you confidently accept the component change. In other words, require that the short-import case (and every input route) is validated according to the same length rule, either natively or via our custom message, before considering the workflow fixed. This way, a short script-filled value will no longer slip through silently.