Measured while implementing objectui#4135 (converging auth.forgotPassword.successDescription's downstream-filled hole on single braces {email}) — not in that PR's scope, and observation-class: no shipped code path in this repo produces the input this describes.
The pattern
ForgotPasswordForm.tsx's marker match (as of objectui#4135) is:
constsuccessMsg=l.successDescription.includes('{email}')
? l.successDescription.replace('{email}',email)
: `${l.successDescription}${email}`;labels.successDescription is a public prop (ForgotPasswordFormLabels), so nothing stops an external consumer of @object-ui/auth from passing a string that still spells the hole the pre-#4135 way, {{email}} (double braces) — e.g. a caller who copied the old convention, or a translation that hasn't been migrated.
The finding
{email} is a literal substring of {{email}} — "{{email}}".includes("{email}") is true (positions 1–7 of {{email}} spell {email} exactly). So a label containing the retired {{email}} spelling does not fall to the (correct, if imperfect) append branch; it partial-matches and .replace() only swaps the inner {email} for the address, leaving the surrounding braces behind:
constlabel='We have sent a link to {{email}}. Check your inbox.';label.includes('{email}') ? label.replace('{email}','user@example.com') : `${label} user@example.com`;// => "We have sent a link to {user@example.com}. Check your inbox."The address renders wrapped in stray literal braces — malformed, but not the double-append shape objectui#4135 was about, and not a crash.
Why the direction changed, not just moved
The relationship is asymmetric, so this is a new failure direction introduced by #4135's fix, not a preexisting one moved sideways:
Why it's dormant rather than broken
Every shipped label for this key — all ten locale packs, ForgotPasswordForm's own built-in default, and both console call sites' inline defaultValues — was migrated to {email} in the same PR (objectui#4135), so nothing in this repository produces the input above today. The only way to hit this is an external consumer's own labels prop still carrying the retired spelling.
Options (no recommendation attached — a component-behavior decision, not a gate finding's to make)
- A. Leave it. The public prop already assumes the caller knows the current marker convention; a stale caller gets a cosmetic (not data-loss) rendering bug, self-correcting the moment they update their copy.
- B. Tighten the match — e.g. a regex with a boundary check (
/(?<!\{)\{email\}(?!\})/) or an explicit {{email}} guard that always prefers the append branch over a partial replace — so a legacy caller degrades to append (correct-if-plain) instead of stray braces. - C. Document it — a one-line comment on the marker check noting the substring relationship, so a future edit to either spelling doesn't reintroduce this blind.
Related: objectui#4135 (introduced the current spelling and this asymmetry).
Measured while implementing objectui#4135 (converging
auth.forgotPassword.successDescription's downstream-filled hole on single braces{email}) — not in that PR's scope, and observation-class: no shipped code path in this repo produces the input this describes.The pattern
ForgotPasswordForm.tsx's marker match (as of objectui#4135) is:labels.successDescriptionis a public prop (ForgotPasswordFormLabels), so nothing stops an external consumer of@object-ui/authfrom passing a string that still spells the hole the pre-#4135 way,{{email}}(double braces) — e.g. a caller who copied the old convention, or a translation that hasn't been migrated.The finding
{email}is a literal substring of{{email}}—"{{email}}".includes("{email}")istrue(positions 1–7 of{{email}}spell{email}exactly). So a label containing the retired{{email}}spelling does not fall to the (correct, if imperfect) append branch; it partial-matches and.replace()only swaps the inner{email}for the address, leaving the surrounding braces behind:The address renders wrapped in stray literal braces — malformed, but not the double-append shape objectui#4135 was about, and not a crash.
Why the direction changed, not just moved
The relationship is asymmetric, so this is a new failure direction introduced by #4135's fix, not a preexisting one moved sideways:
auth.forgotPassword.successDescriptionuses{{email}}, its sibling three lines away uses{seconds}#4135 (marker checked for{{email}}): a label spelled with single braces ({email}) would NOT match.includes('{{email}}')— double braces are not a substring of a single-brace string — so it fell cleanly to the append branch. No stray-brace failure mode existed in that direction.auth.forgotPassword.successDescriptionuses{{email}}, its sibling three lines away uses{seconds}#4135 (marker checks for{email}): a label spelled with the old double braces ({{email}}) DOES match.includes('{email}'), because single braces ARE a substring of double braces — so it partial-matches instead of falling to append.Why it's dormant rather than broken
Every shipped label for this key — all ten locale packs,
ForgotPasswordForm's own built-in default, and both console call sites' inlinedefaultValues — was migrated to{email}in the same PR (objectui#4135), so nothing in this repository produces the input above today. The only way to hit this is an external consumer's ownlabelsprop still carrying the retired spelling.Options (no recommendation attached — a component-behavior decision, not a gate finding's to make)
/(?<!\{)\{email\}(?!\})/) or an explicit{{email}}guard that always prefers the append branch over a partial replace — so a legacy caller degrades to append (correct-if-plain) instead of stray braces.Related: objectui#4135 (introduced the current spelling and this asymmetry).