Extend Expression Parser Rejects 'for' as a Property Name (Reserved Word Conflict)
What it means
A PMD or AMD binding expression referenced a property literally named 'for' (for example event.for.id), and the expression parser rejected it. 'for' is a reserved keyword in the AMD/PMD expression grammar (used for loop constructs), so the parser cannot treat it as an ordinary property name in a dot path, even though the surrounding JSON is otherwise valid.
Troubleshooting
- Read the validation error carefully: 'X expected, got Y' where Y is a plain word (not a symbol) usually means Y collided with a reserved keyword, not that a field is missing.
- Open the flagged endpoint or binding expression and find the exact dot-path segment matching the reported token.
- Cross-check the segment name against the AMD/PMD reserved word list (for, if, else, var, and similar control-flow keywords are common collisions), not just against your own model field names.
- Confirm the underlying data actually uses that property name (for example an upstream API returning a field literally called 'for') rather than assuming it is a typo in your own code.
Wrap or reference the property through a path that does not place the reserved word directly after a dot, or rename the intermediate variable holding it if you control the model, then re-validate.
When mapping external API fields into Extend endpoints or model events, cross-check field names against the AMD/PMD reserved word list before wiring bindings, and treat any 'identifier expected, got X' validation message as a keyword collision first before searching for a missing-field bug.