pedroreyesalvarado commented on PR #8637: URL: https://github.com/apache/texera/pull/8637#issuecomment-6197072422
Thanks @carloea2 — all three are fixed in 55f5ccd and 88b22d9, each reproduced against the service before the fix and confirmed failing without it. **Suggestion bound to its workflow.** You were right that the operator id alone does not identify the context, and the reproduction you described holds. `FixState` now carries the workflow it was made for, checked when the reply lands, before the write, and again after the unlock wait — that last one matters most, since the wait can take seconds and nothing stopped the user navigating during it. **Retry after a failed apply.** This was the worst of the three and entirely my doing: I added `apply_failed` to the template two days earlier and left the guard in `applyFix` matching only `ready`, so the panel offered a button that silently did nothing. It is retryable now; every check below re-reads the operator and runs again, so a retry is not a shortcut past validation. **Structured configuration values.** Arrays and objects are refused rather than parsed. Validating a replacement against the operator's JSON schema is a larger change than the four error shapes here need, and none of them touches a structured field, so refusing with a clear message beats guessing. --- Your review also prompted me to audit what my own fixes touched, which turned up two more: **The frame still scoped by operator id alone.** Refusing the write was only half of your first finding — the tab went on *rendering* a suggestion from another workflow, so the user saw a diff for a graph they had left and only learned otherwise by clicking Apply. Fixed in 88b22d9; the frame now renders nothing unless the state names both this operator and the open workflow. **An apply reported over whatever replaced it.** During the unlock wait, any other failed operator's frame shows idle with a live Analyze button. Start an analysis there and the earlier apply announced "Fix applied" on top of it. The apply now reads the analysis counter when it begins and stays quiet if the panel has moved on. One more worth mentioning because it explains a gap in what I could tell you before: the service spec had been injecting the real `OperatorMetadataService`, which fetches from its constructor, so every TestBed issued a live request. With enough tests the suite stopped reporting at all rather than failing — it was silently useless for a week. Stubbed now. I also chased three further suspicions and they are all unreachable: the occurrence count going stale, the panel being destroyed mid-apply, and the operator being deleted during an analysis. All three are protected by the same thing — workflow modification is locked for as long as a run is live, which is exactly the window between analysing a traceback and applying the fix. I mention it in case it saves you reproducing them. 144 specs across the result panel, 6701 across the frontend, lint and production build clean. The branch is current with main. -- 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]
