The guard only undoes exponent notation for positive exponents, but Decimal.__str__ also uses scientific notation for sufficiently negative exponents (adjusted exponent below -6). So small <floatstring> elements now render in exponent notation on a task command line -- the exact thing the comment two lines below says must never happen:

• "0.0000001" becomes Decimal("1E-7") and renders as 1E-7 (previously the source text 0.0000001 reached the renderer verbatim)
• "0.00000025" becomes Decimal("2.5E-7") and renders as 2.5E-7

This is a behaviour regression for these values, not merely a missed normalization: before this validator the raw string was carried through unchanged.

The parametrized cases only cover exponents that shift upward ("100", "1E+2"), which is why it is not caught. Consider handling both directions: when the normalized exponent is negative and value.adjusted() < -6, return Decimal(format(value, "f")) to force plain notation -- and add a "0.0000001" case to test_floatstring_elements_carry_their_value.

Confirmed and fixed. Measured before/after on "0.0000001": the landed code rendered 1E-7 (str(Decimal) switches to exponent notation once the adjusted exponent drops below -6, which the positive-exponent guard never covered), and it is a regression, since keeping the source text rendered 0.0000001. It now renders 0.0000001 via format(value, "f"), which is plain at every magnitude — note this is a deliberate divergence from openjd-rs at the extremes, whose f64 Display emits 1e-07 here, because exponent notation must not reach a task command line.

Decimal.normalize() runs under the ambient decimal context, so it rounds to getcontext().prec significant digits (28 by default). That makes this a silent, lossy rewrite of a task parameter value:

• "1.1234567890123456789012345678901234567890" is rounded to 28 significant digits instead of being carried through exactly, and
• because the context is process-global mutable state, an embedding application that has done getcontext().prec = 5 anywhere changes what range values this library produces — "1.234567" would become 1.2346.

Before this change the source text reached the renderer unchanged, so no precision could be lost. Since the only goal here is to strip redundant leading/trailing zeros, the operation does not need the default context: consider value.normalize(context=Context(prec=...)) with an explicitly large precision, or drop normalize() and strip the zeros without a context-sensitive arithmetic operation.

Confirmed and fixed. Measured: normalize() cut a 41-significant-digit element to 1.234567890123456789012345679 at the default prec=28, and with an embedding app setting getcontext().prec = 5 the same template rendered 1.2346 — library output was a function of host process state. Replaced with format(value, "f") plus text-level zero stripping, neither of which consults the context; verified byte-identical output under prec=5, and pinned by a new localcontext() regression test.

This leaves the model rendering the same denoted number two different ways on a FLOAT parameter, depending only on how the element was spelled in the template:

• range: [1.0] (a <float> literal) renders 1.0 — deliberately preserved, per this comment.
• range: ["1.0"] (a <floatstring>) renders 1 — normalize() strips the fractional zero, and the new test pins this ("0.0" -> "0").

But §2.4 defines a <floatstring> as "a string whose value is the string representation of" a float, and "1.0" is the string representation of the float 1.0. By the PR's own reasoning the element denotes 1.0, so a FLOAT parameter emitting --frame 0 where the template said "0.0" looks like the same class of bug being fixed here, in the opposite direction. It also means the two forms disagree even though the spec treats them as alternate spellings of one value.

Worth confirming against openjd-rs / the conformance suite before pinning "0.0" -> "0" in a test: if openjd-rs renders 0.0 for a "0.0" floatstring, then trailing-zero stripping should be limited to zeros beyond the first fractional digit (i.e. keep at least one), rather than reducing an integral float to bare digits.

You are right, and I probed openjd-rs to settle it rather than argue from the fixture, which does not cover an integral float (3.4.1.2 uses ['1.5', '02.50']). The Rust CLI renders "1.0" as 1.0, "0.0" as 0.0, "007" as 7.0 and "100" as 100.0, so my normalize() was too aggressive and produced a spelling-dependent split against the <float> literal 1.0. FLOAT elements now always keep one fractional digit, "-0.0" renders 0.0 since the denoted number is unsigned (matching Rust), and the test that pinned "0.0" -> "0" is updated along with 007, 100 and 1E+2.

quantize(Decimal(1)) raises InvalidOperation whenever the result would need more than getcontext().prec digits, and that exception is swallowed by the except (ValueError, ArithmeticError) below — which returns the original string. So for a large-exponent element the "never renders in exponent notation" guarantee falls back to whatever the template wrote:

• range: ["1E+30"] on a FLOAT parameter -> normalize() gives Decimal("1E+30"), exponent 30 > 0, quantize needs 31 digits > prec 28 -> InvalidOperation -> the function returns the string "1E+30", which renders as 1E+30.

Not a regression (the raw text was passed through before), but the fallback silently defeats the stated invariant rather than reporting anything. If exponent notation genuinely must never reach a task command line, formatting with format(value, "f") avoids the precision-bounded quantize entirely and handles arbitrary exponents in one step.

Confirmed exactly as described, and fixed. Measured: Decimal("1E+30").normalize().quantize(Decimal(1)) raises InvalidOperation because the result needs 31 digits against prec=28, the except (ValueError, ArithmeticError) swallowed it, and range: ["1E+30"] fell back to the raw string 1E+30 — defeating the invariant the guard existed to hold; "123456.75" under a narrowed context hit the same path. quantize is gone entirely: format(value, "f") has no precision bound, so "1E+30" now renders 1000000000000000000000000000000.0 and there is no fallback path left for a finite value.

The docstring says the element is returned unchanged when it "does not denote" a number, but int() / Decimal() accept a strictly wider grammar than <intstring> / <floatstring>, so some non-conforming elements are silently rewritten instead of passed through:

• "1_0" -> 10 (PEP 515 underscores)
• " 5 " -> 5 (surrounding whitespace)
• "+7" -> 7 (explicit sign dropped from the rendered value)
• non-ASCII decimal digits, e.g. "٣" -> 3

These are reachable from a literal template range: the template-layer check (validate_int_fmtstring_field via validate_list_field) also uses int(), and validate_list_field discards its validator's return value, so today the raw text is what reaches the renderer. After this change the rendered task value differs for these inputs.

Edge-case severity, but since the point of the change is to make the rendered value match what the element denotes per the spec, it may be worth matching against the spec's grammar (e.g. a regex for <intstring> / <floatstring>) rather than delegating to Python's more permissive parsers.

Accurate on the facts — int() and Decimal() do accept more than <intstring>/<floatstring>, and I reproduced "1_0" -> 10, " 5 " -> 5 and "+7" -> 7 — but I am declining this one. Every input that reaches it is a template already malformed under the spec grammar, so the only behaviour change would be swapping one undefined outcome for another, and a regex gate on both grammars is disproportionate to that. If you want the grammar enforced I would rather do it as validation at the template layer where the element type is already checked, as its own change with its own conformance fixture.

The else elem branch skips every non-str element, so the "a range element never renders in exponent notation" invariant that _normalized_range_element establishes only holds for the <intstring>/<floatstring> spelling. A numeric FLOAT element takes this branch and can still render in exponent notation:

• _coerce_typed_range_elements (the typed_resolve_coerce hook) appends elem.item() for the engine float variant, i.e. a native Python float. TaskRangeList = list[Union[TaskParameterStringValueAsJob, int, float, Decimal]] lists float, so pydantic's smart union keeps it as float on an exact-type match. A LIST[FLOAT] job parameter resolved whole-field into a FLOAT range (range: "{{Param.Values}}") with an element like 1e16 or 1e-7 therefore reaches RangeListIdentifierNode.__getitem__, which does str(self.range[index]) — str(1e+16) is '1e+16' and str(1e-07) is '1e-07', so the task command line gets --frame 1e+16.
• A YAML <float> literal written in exponent form (range: [1.0e+16]) lands as a Decimal whose str() is likewise 1E+16.

So the guard covers range: ["1E+2"] (there is a test for it) but not the numerically-typed forms of the same value, which is the asymmetry the quantize branch two functions up exists to prevent.

If exponent notation must never reach a task command line, the guard belongs after the str/non-str split — e.g. normalize the exponent for any Decimal/float element as well, rather than only for elements that arrived as text.

Correct on the facts, but pre-existing rather than a regression, so I am declining it here rather than ignoring it. Checked on mainline (f7ca58f): a Decimal("1.0e+16") element already rendered 1.0E+16 there, a float 1e16 rendered 1e+16 and 1e-7 rendered 1e-07, and this branch leaves all three byte-identical — numeric elements were passed through untouched before it and still are. Normalizing them is deliberately out of scope for this PR because that pass-through is what keeps 3.4--float-parameter passing (it pins TASK:Scale=1.0 from a literal 1.0), so it needs its own conformance decision about what a numerically-typed <float> element renders as; worth its own issue.

format(value, "f") is unbounded in output size, and the input is attacker-controlled template text, so this looks like a memory-exhaustion hazard on job creation.

Decimal("1e999999999") constructs fine — Emax/Emin from the context constrain arithmetic results, not construction from a string — and is_finite() is True, so the guard above does not stop it. format(d, "f") then has to materialize the full plain-notation expansion, i.e. on the order of 10^9 characters for that exponent (and likewise for a large negative exponent such as "1e-999999999"). That is a multi-gigabyte allocation, or an effectively unbounded CPU/memory spike well before that.

It is reachable from a plain template: a FLOAT task parameter range: ["1e999999999"] passes the template-layer check, since validate_float_fmtstring_field only does Decimal(str(value)) and imposes no exponent bound. The element then arrives here as a str on the instantiation target and gets expanded. The previous str()/normalize() formulations did not have this property — str(Decimal) keeps exponent notation and is O(digits) — so this is specific to the format(..., "f") approach.

Worth bounding the exponent before expanding, e.g. reject (or leave as text) when value.adjusted() or -value.as_tuple().exponent exceeds some sane limit, so the plain-notation length is capped by construction rather than by the input.

Confirmed and fixed. Measured: Decimal("1e999999999") is finite exactly as you say, and the expansion is exponent+1 characters — parsing range: ["1e100000000"] on the instantiation target cost 0.37s and 266 MiB peak RSS from 11 characters of template text, and the 1e999999999 case killed the probe process outright. The length is now computed from adjusted()/as_tuple().exponent before anything is materialized, bounded at the 1024-character cap TaskParameterStringValueAsJob already enforces on this field, and an element over it keeps its source text — "1e999999999" now parses in 0.01 ms at 42 MiB.

Normalization can make an element longer than the 1024-char cap the field type enforces, so an input that validated before this change can now fail (or silently change type) at the same point.

Elements of TaskRangeList are Union[TaskParameterStringValueAsJob, int, float, Decimal] and TaskParameterStringValueAsJob carries StringConstraints(max_length=1024). format(value, "f") turns a short source text into its full plain-notation expansion, so a FLOAT element written as "1E+1030" — 7 characters, well under every existing limit and accepted by the template-layer check — becomes a 1033-character string here. That fails the str member of the union, and rather than erroring cleanly pydantic then falls through to the numeric members in lax mode, where float("1000…0.0") overflows to inf. Either way the result is wrong for a template that was previously valid: an error on a conforming template, or a rendered task value of inf.

This is distinct from the unbounded-expansion concern on the format(..., "f") line above (which needs an exponent in the billions to hurt): here the threshold is around 1e1024, so it is well within what a template can plausibly contain and it costs nothing to trigger. A single exponent/length bound before expanding would cover both.

Also worth a test: the existing coverage stops at "1E+30", which stays comfortably under the cap.

Confirmed and fixed, with one correction to the predicted mechanism. Measured on the instantiation target: the threshold is a 1025-character expansion, and "1E+1022" fell through the str member to int and rendered 1023 digits rather than inf, while "1E-1023" fell through to float, underflowed and rendered 0.0 — silently losing the value; mainline rendered both as their source text, so both were previously valid. Both directions are now bounded by that same 1024-character cap before expansion, "1E+1021" and "1E-1022" expand to exactly 1024 and are still normalized, and there are tests one past the cap and at it.