The GitHub Actions job "Required Checks" on texera.git/loop-body-state has succeeded. Run started by GitHub user aglinxinyuan (triggered by aglinxinyuan).
Head commit for run: 852ba0c593c70d96fbced505e078cb7ea9128f46 / Xinyuan Lin <[email protected]> fix(amber): pass unstamped boundary states through LoopEnd instead of consuming them Follow-up to #6661 (review discussion r3648708075). A loop-body operator that emits its own boundary state (produce_state_on_start/finish -- a public API on both engine sides) sends it with the "no loop" envelope (counter 0, loop_start_id ""). The LoopEnd matching branch treated EVERY counter-0 frame as the loop's own boundary state: it captured the back-jump id from the frame (clobbering the real id with "") and handed the state to run_update, which expects the loop `table` payload (KeyError). Either way the loop broke with "no loop-back state URI configured for LoopStart ''". A real loop state is always stamped -- the matching LoopStart stamps its own id on every iteration's output state -- so the consumer can key on the stamp: an UNstamped counter-0 frame at a LoopEnd is now forwarded downstream unchanged, skipping the operator, like any default pass-through. The captured back-jump id is untouched. Also adds the comment the review asked for at the two Scala boundary-state emit sites (StartChannelHandler / EndChannelHandler), documenting that their "no loop" envelope defaults are deliberate and what the Python LoopEnd runtime does with them. Tests: a unit test pins the forward/skip/no-clobber behavior for unstamped frames (the stamped-consume test is unchanged), and a new LoopIntegrationSpec e2e case runs a loop whose body is a Python UDF emitting boundary state via produce_state_on_finish -- it crashes without this fix and completes 3 iterations with it. Report URL: https://github.com/apache/texera/actions/runs/30219899307 With regards, GitHub Actions via GitBox
