kz930 opened a new pull request, #7584: URL: https://github.com/apache/texera/pull/7584
### What changes were proposed in this PR? Clearing a text or number field in the property panel left the box empty on screen while the operator kept the value it held before, so the workflow ran on a value the user had removed and could no longer see. Setting CSV File Scan's Limit to 5 and clearing it left the scan reading 5 rows, with nothing on screen saying so, and the value came back on the next reload. The panel is not at fault. It sends the properties it has, and a cleared field is simply not among them. Formly drops a cleared text field from the model outright; a cleared number arrives as `null`, which `onFormChanges` filters out. Either way the properties reaching the shared model no longer carry that key. Instrumenting the panel shows exactly that: after clearing Delimiter, the object handed to `setOperatorProperty` has no `customDelimiter`, and the operator still holds the old value a moment later. `updateYTypeFromObject` had no way to act on that. It walks the union of old and new keys and, for each, updates a value in place or sets a new one. For a key the new object no longer carries it did neither: the in-place update refuses an undefined value, and the `set` that follows is guarded on the value not being undefined. The old entry stayed in the Y.Map, and a removal could not be expressed at all. It now deletes such a key. Membership decides rather than the value, so a key carried with an explicit `undefined` still takes the update path and only a key that is gone counts as a removal. The array branch is untouched. Removals there are already handled by the length comparison, which deletes the old items a shorter new array leaves behind. Clearing now does what the panel shows. A property with a schema default comes back as that default when the panel is next rendered, which is one of the two behaviours the issue asks for; a property without a default stays empty. ### Any related issues, documentation, discussions? Closes #7394 The issue also read the retained value as evidence that an empty string cannot be stored from the UI. That part has been withdrawn from it: an absent property deserializes to its Scala field initializer, so for a field where an empty value is meaningful, removing the property already produces it. `SklearnPredictionOpDesc.groundTruthAttribute` initializes to `""` and its generated code branches on `!= ""`, so clearing the box is exactly how a user goes back to ignoring no ground-truth column. ### How was this PR tested? The unit test that pinned the old behaviour is updated rather than removed. It came from #6653, a test-only PR adding coverage, and described what the function did rather than what it should do; its assertion that a dropped key is retained is now an assertion that it is deleted. A second case is added for the distinction the fix rests on: a key carried with an explicit `undefined` is left alone. `shared-editing.interface.spec.ts` passes with 29 cases, and the specs around it that write operator properties pass together with it: `workflow-graph`, `shared-model-change-handler`, `workflow-action.service`, `operator-property-edit-frame.component`, `preset.service` and `workflow-compiling.service`, 465 cases in total. The reproduction from the issue was run in the browser before and after. Before: Delimiter set to `X` survives a reload, is cleared, and comes back as `X`. After: the same sequence leaves `,`, the schema default, and CSV File Scan's Limit set to 5 and cleared stays empty across a reload. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5) -- 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]
