Problem
Templated values are substituted after the initial JSON schema validation, but the resulting values are not consistently validated before downstream code uses them. This can turn a configuration mistake into an uncaught runtime exception instead of a useful parser error.
For example, a component can contain a string-only field such as a React component path:
{
"type": "react-component",
"path": "{{n}}",
"response": []
}
If the template value is numeric, such as n = 1, template expansion produces a number for path. The parser then calls string-specific logic such as path.includes(...) while checking the component, which can throw a TypeError rather than returning a structured configuration error.
The same risk applies to other templated fields whose final value must have a specific type.
Expected behavior
- Validate the final value of templated fields against the applicable schema or field contract.
- Return a normal parser error with the field path, received value type, and a useful remediation message.
- Do not allow malformed templated values to reach path resolution, rendering, sequence generation, or participant startup.
- Preserve valid exact-token substitutions in fields that intentionally accept non-string values, such as numeric component parameters.
Suggested scope
Audit both factor compilation and participant-level materialization, including fields such as component paths, stylesheet paths, asset paths, response properties, and templated parameters. Add focused tests covering valid substitutions, invalid type substitutions, unresolved templates, and nested templated fields.
This complements #1398, which tracks the templating feature itself; this issue focuses on safe validation and error handling for the values produced by templating.
Problem
Templated values are substituted after the initial JSON schema validation, but the resulting values are not consistently validated before downstream code uses them. This can turn a configuration mistake into an uncaught runtime exception instead of a useful parser error.
For example, a component can contain a string-only field such as a React component path:
{
"type": "react-component",
"path": "{{n}}",
"response": []
}
If the template value is numeric, such as n = 1, template expansion produces a number for path. The parser then calls string-specific logic such as path.includes(...) while checking the component, which can throw a TypeError rather than returning a structured configuration error.
The same risk applies to other templated fields whose final value must have a specific type.
Expected behavior
Suggested scope
Audit both factor compilation and participant-level materialization, including fields such as component paths, stylesheet paths, asset paths, response properties, and templated parameters. Add focused tests covering valid substitutions, invalid type substitutions, unresolved templates, and nested templated fields.
This complements #1398, which tracks the templating feature itself; this issue focuses on safe validation and error handling for the values produced by templating.