Add a check for when the command is canceled by the program on Window…

[charles7668]

Close #29509

Windows, unlike Linux, does not have signal-specified exit codes. Therefore, we should add a Windows-specific check for Windows. If we don't do this, the logs will always show a failed status, even though the command actually works correctly.

If you check the Go source code in exec_windows.go, you will see that it always returns exit code 1.

The exit code 1 does not exclusively signify a SIGNAL KILL; it can indicate any issue that occurs when a program fails.

[wxiaoguang]

Could the code be simplified to this?

if ctx.Err() != nil {
    return ctx.Err()
}
return err

I think it should cover all cases.

• If the command is killed by context, then use context error
• Otherwise use command error

(I haven't carefully thought about this problem at the moment, just a brief idea)

[charles7668]

Could the code be simplified to this?

if ctx.Err() != nil {
    return ctx.Err()
}
return err

I think it should cover all cases.

* If the command is killed by context, then use context error

* Otherwise use command error

(I haven't carefully thought about this problem at the moment, just a brief idea)

this is hard to test , considering the context may be canceled anywhere by the parent, I can't be sure that the error always returns before the context is canceled. If not, the real error will be ignored.

[wxiaoguang]

Hmm, I think it's worth to do the change. According to the "Context" document:

	// If Done is not yet closed, Err returns nil.
	// If Done is closed, Err returns a non-nil error explaining why:
	// Canceled if the context was canceled
	// or DeadlineExceeded if the context's deadline passed.
	// After Err returns a non-nil error, successive calls to Err return the same error.
	Err() error

I think using ctx.Err() correctly would make code more correct. If you have worries about it .... I could do such "refactoring", if I am wrong I will follow it and propose related fixes. 😁

[wxiaoguang]

The check is pretty strict, so it could be good enough.