yohimik commented on issue #50363: URL: https://github.com/apache/arrow/issues/50363#issuecomment-5610501841
I reproduced the stale-run selection against [`utils-watch-gh-workflow.sh` at df40dd4](https://github.com/apache/arrow/blob/df40dd400bbaea59e621123ead6c41a51f0fc654/dev/release/utils-watch-gh-workflow.sh) with a stub `gh`: `run list` returns the previous successful ID while the newly dispatched run is not yet visible. The helper immediately watches the old ID and exits 0. No build, signing or publication was performed in this reproduction. A useful regression set would cover: - An old success remains visible before the new run appears. - Two dispatches use the same tag and workflow. - The selected run fails or is cancelled. - No matching run appears before a bounded deadline. The helper already uses `--exit-status`, so failure propagation is present; identifying the correct invocation is the gap. Capturing the dispatch's run ID, where the supported CLI/API provides it, avoids the discovery race. Otherwise a unique dispatch input exposed in the run name is stronger than tag, SHA or creation time alone. Retain that ID for recovery, then verify the MSI belongs to that invocation before signing it. The final [25.0.0 release](https://github.com/apache/arrow/releases/tag/apache-arrow-25.0.0) currently contains the MSI and DLL assets. This is a remaining script regression, not a claim those artifacts are missing. Disclosure: I maintain [dispat](https://github.com/yohimik/dispat), where dependency ordering and recorded completion are useful for multi-stage releases. An external workflow adapter still has to preserve this invocation identity; orchestration alone would not fix the wrong-run lookup. -- 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]
