aglinxinyuan opened a new issue, #8636: URL: https://github.com/apache/texera/issues/8636
### Problem The property panel has no notion of control blocks or loop variables. A user who wants an operator inside a LoopStart/LoopEnd block to use the loop's variable `K` has no way to say so: a numeric field rejects anything but a number, nothing tells her which variables the enclosing block declares, and the workflow compile request would carry whatever she typed as a plain literal. ### Proposal For an operator that lies inside a block (reachable from a LoopStart and reaching a LoopEnd): 1. **Accept `$name` references** in property fields of any primitive type (string, integer, number, boolean). The field keeps the text `$K`; the JSON-schema validation treats a value matching `^\$[A-Za-z_]\w*$` as valid for that field, and the value is sent unchanged in `operatorProperties` (the backend records and binds it; see the companion backend issue). 2. **Autocomplete** the reference from the variables the enclosing LoopStart operators declare in their `init()` code field (top-level assignments such as `K = 2; prev = ...`), and flag a `$name` that no enclosing block declares. 3. **Block membership** as a reusable utility on the workflow graph (an operator's enclosing LoopStart operators), so the panel, validation and later features share one definition. Operators outside any block keep today's behavior. ### Acceptance - Unit tests (Vitest) for block membership on straight, branching and nested graphs, for `init()` variable extraction, and for the `$name` validator. - Typing `$K` into the cluster-count field of an operator inside a block is accepted and sent as `"$K"`; the same in an operator outside a block is rejected as before. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
