Repository navigation
test(shell): 报告剪贴板 owner 的首次失败步骤 (#85) - #218
Conversation
The message used the current cleanup step together with the first error code, which made a stale cleanup step look like the failing call; it now prints failure_step and state_step separately.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0a9048948c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| std::string ready_failure(DWORD wait_status) const { | ||
| return std::string("clipboard owner failed its bounded ready handshake: mode=")+ | ||
| (delayed_?"delayed":"occupied")+" step="+step_.load()+ | ||
| (delayed_?"delayed":"occupied")+" failure_step="+failure_step_.load()+ |
There was a problem hiding this comment.
If the ready handshake times out before the worker records a failure, failure_step_ is still nullptr. The constructor explicitly calls ready_failure() when ready_status != WAIT_OBJECT_0, even when error_ is zero, so concatenating this pointer into a std::string invokes undefined behavior instead of reporting the blocked step. This can crash the scenario before its diagnostic is emitted and before stop() runs. Load the pointer once and substitute the current step or a non-null sentinel when no failure has been recorded.
Useful? React with 👍 / 👎.
问题
剪贴板 owner 的失败文案用的是当前步骤（
step_），而win32_error用的是首次失败的错误码（native_error_）。所以上一条样本：看起来像 DestroyWindow 失败（错误码 5），但 5 其实是更早那次失败的错误码，DestroyWindow 只是清理时最后更新到的步骤——真正的失败步骤被掩盖了。
修改
失败文案改为同时给出两个字段：
failure_step_本来就已经被record_failure()记录了，只是没有输出。边界
failure_step/secondary_failure_step等仍按原样产出）；Refs #85 #99