microcks test exits with code 1 (contract failure) instead of code 11 (connection) when polling loop times out
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 cmd/testExecutor.go 的 runTestAndWait 开始:轮询循环可能在 inProgress 仍为 true 时退出并返回 nil 错误,因此 cmd/test.go 将其视为 errors.ErrTestFailed,而 cmd/exit.go 将其映射为退出码 1。添加循环后的 inProgress 检查,将超时错误包装为 errors.KindConnection,然后使用 issue 中的 Python mock 服务器加上 go run main.go test ... --waitFor=100milli 验证 CLI 现在以 11 而非 1 退出。对照 documentation/error-handling.md 交叉检查预期的错误码,并运行现有的 Go 测试。
由索引模型根据 Issue 内容生成。
描述
Describe the bug
While going through the changes in PR #540 and the new documentation/error-handling.md, I noticed a gap in how the test polling loop handles timeouts.
In cmd/testExecutor.go, runTestAndWait polls the server in a loop until the test finishes or the deadline passes:
for nowInMilliseconds() < future {
testResultSummary, err := mc.GetTestResult(testResultID)
if err != nil {
return false, "", fmt.Errorf("checking test result: %w", err)
}
success = testResultSummary.Success
inProgress := testResultSummary.InProgress
if !inProgress {
break
}
time.Sleep(2 * time.Second)
}
return success, testResultID, nil
If the server hasn't finished by the time the deadline runs out, the loop exits with inProgress still true, but the function returns nil for the error. No timeout is ever flagged.
Back in cmd/test.go, the caller sees err == nil and !success, so it returns errors.ErrTestFailed:
success, testResultID, err := runTestAndWait(mc, params)
if err != nil {
return err
}
if !success {
return errors.ErrTestFailed // exit code 1
}
And cmd/exit.go maps that to exit code 1:
case stderrors.Is(err, errors.ErrTestFailed):
// A clean run with a non-conforming result — pytest-style exit 1.
return 1
The problem is that a polling timeout is not a contract conformance failure, it's an infrastructure/connection issue. According to error-handling.md, exit code 1 is strictly for "a clean run whose result did not conform". A timeout means the CLI never got a final result at all.
Expected behavior
When the polling loop runs out of time with inProgress still true, it should return a proper timeout error wrapped as KindConnection, something like:
if inProgress {
return false, testResultID, errors.Wrap(errors.KindConnection,
fmt.Errorf("test polling timed out after %dms waiting for result %s",
params.waitForMillis+10000, testResultID))
}
This would cause ExitCodeFor to return 11 and Handle to print a clear error to stderr, so CI/CD pipelines can tell apart "API contract broken" (exit 1) from "server was too slow or unreachable" (exit 11).
Actual behavior
MicrocksClient got status for test "test-hanging-1" - success: false, inProgress: true
MicrocksTester waiting for 2 seconds before checking again or exiting.
MicrocksClient got status for test "test-hanging-1" - success: false, inProgress: true
MicrocksTester waiting for 2 seconds before checking again or exiting.
... repeats until deadline ...
Test test-hanging-1: FAILURE (0ms)
Full TestResult details are available here: http://127.0.0.1:8888/#/tests/test-hanging-1
exit status 1
$ echo $?
1
The CLI exits with code 1 and falsely reports a contract test failure (FAILURE 0ms), with no error indicating that the run actually timed out.
How to Reproduce?
- Start a mock server simulating a test that remains in progress:
python3 -c '
from http.server import HTTPServer, BaseHTTPRequestHandler
class MockServer(BaseHTTPRequestHandler):
def do_POST(self):
self.send_response(201)
self.send_header("Content-Type", "application/json")
self.end_headers()
self.wfile.write(b"{\"id\":\"test-hanging-1\"}")
def do_GET(self):
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.end_headers()
self.wfile.write(b"{\"id\":\"test-hanging-1\",\"success\":false,\"inProgress\":true}")
def log_message(self, *args): pass
HTTPServer(("127.0.0.1", 8888), MockServer).serve_forever()
'
-
Run the test command with a short wait deadline:
go run main.go test "MyAPI:1.0" "http://localhost:8080" HTTP --microcksURL=http://127.0.0.1:8888 --waitFor=100milli -
Check the exit status: It returns 1 instead of 11.
Root cause: in cmd/testExecutor.go (lines 76–103), the loop ends when nowInMilliseconds() >= future, but falls through to return success, testResultID, nil without verifying if inProgress was still true.
Microcks version or git rev
main
Install method (docker-compose, helm chart, operator, docker-desktop extension,...)
CLI
Additional information
The fix is small and self-contained, only cmd/testExecutor.go needs to change (add a post-loop inProgress check). All three callers of runTestAndWait (cmd/test.go, and two places in cmd/testDryRun.go) already have if err != nil { return err } guards, so they'll handle the new error correctly without any changes.
- 主要语言
- Go
- 星标
- 58
- 派生
- 72
- 平均合并
- 1 天 9 小时
- 30 天内合并 PR
- 28
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microcks/microcks-cli 的其他 Issue
-
Default configuration path falls back to the current directory when the home directory cannot be determined可能已有人在做 @Sarthak-Shreshtha01 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
microcks/microcks-cli#583 · 2 条评论 ·
维护者通常 1 天内回复
-
bug: YAML parse error in config is silently swallowed, login overwrites all other contexts可能已有人在做 @Sarthak-Shreshtha01 于 6 天前认领。 未关闭component/cli kind/bug
难度 2/5 1-3 小时 新手友好度 76/100
microcks/microcks-cli#572 · 5 条评论 ·
维护者通常 1 天内回复
-
import-dir uploads secondary artifacts before their primary API definition可能已有人在做 @doraem-on 于 13 天前认领。 未关闭component/cli kind/bug
难度 2/5 1-3 小时 新手友好度 88/100
microcks/microcks-cli#561 · 3 条评论 ·
维护者通常 1 天内回复
-
TEST: `ConnectAndGetToken` Returns Error on Non-200 Response可能已有人在做 @aniket866 于 16 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
microcks/microcks-cli#554 ·
维护者通常 1 天内回复
-
Empty `AuthToken` Causes Cryptic JWT Parse Error可能已有人在做 @aniket866 于 16 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 86/100
microcks/microcks-cli#551 ·
维护者通常 1 天内回复
查看 microcks/microcks-cli 的全部 Issue
相似的 Issue
-
component/server severity/minor type/bug
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
diagnose globalnet reports a failure for every exported headless Service可能已有人在做 @kurtyoon 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
submariner-io/subctl#1948 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
-
help wanted
难度 2/5 1-3 小时 新手友好度 70/100
meshery-extensions/meshery-mcp-server#63 · 1 条评论 ·
-
help wanted
难度 2/5 1-3 小时 新手友好度 62/100