Logging into a locally started instance clears its container reference, causing stop to do nothing
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 cmd/login.go 开始，issue 指出 login 会替换已保存的上下文，接着追踪该上下文的写入方式。使用单独的配置文件，通过 issue 中的三个命令重现问题，然后检查 login 是否保留实例字段，以及 microcks stop 是否随后停止容器。
由索引模型根据 Issue 内容生成。
描述
Describe the bug
After starting a local Microcks instance with the CLI, logging into the same server clears the instance reference from its saved context.
A subsequent microcks stop reports that no instance is associated with the context and exits successfully, even though the container is still running.
I reproduced this using a separate config file and an authentication-disabled Microcks instance.
Expected behavior
Logging into the same server should preserve its existing local instance reference. Running microcks stop afterward should stop the container created by microcks start.
Actual behavior
Before login, the saved context contains:
instance: microcks-login-repro
After login, it becomes:
instance: ""
Running stop then prints: No instance is associated with this context
The command exits with code 0, but Docker still reports the container as running. The Microcks API also continues to return HTTP 200.
How to Reproduce?
With Docker running, execute the following commands using a separate config file:
microcks start --name microcks-login-repro --port 18585 --rm --ready-timeout 120s --config repro-config.yaml
microcks login http://localhost:18585 --config repro-config.yaml
microcks stop --config repro-config.yaml
Check whether the container is still running:
docker inspect --format '{{.State.Running}}' microcks-login-repro
The output is: true
You can also compare repro-config.yaml before and after login to see that the context’s instance field has been cleared.
As a control, restoring the config saved before login and repeating the same stop command successfully stopped and removed the container.
To clean up manually after reproducing:
docker stop microcks-login-repro
Microcks version or git rev
36f1028f877a5f4502633f574aac627e7d25dc53
Install method (docker-compose, helm chart, operator, docker-desktop extension,...)
No response
Additional information
The likely cause is in cmd/login.go: login replaces the existing context with a ContextRef containing only Name, Server, and User, leaving out the Instance field previously saved by start.
- 主要语言
- Go
- 星标
- 59
- 派生
- 75
- 平均合并
- 4 天 5 小时
- 30 天内合并 PR
- 15
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microcks/microcks-cli 的其他 Issue
-
WatchConfig.UpsertEntry silently deletes existing contexts when re-upserting a watched file可能已有人在做 @aryarathoree 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
microcks/microcks-cli#610 · 5 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
microcks/microcks-cli#608 · 2 条评论 ·
维护者通常 1 天内回复
-
KeycloakClient strips realm path when realm URL lacks trailing slash可能已有人在做 @aryarathoree 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
microcks/microcks-cli#606 · 1 条评论 ·
维护者通常 1 天内回复
-
Windows test failures in MockFileSystem.Walk due to path separator可能已有人在做 @dipak0000812 于 5 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
microcks/microcks-cli#601 · 1 条评论 ·
维护者通常 1 天内回复
-
Bug: `testEndpoint` URL Scheme Not Validated可能已有人在做 @aniket866 于 5 天前认领。 未关闭
难度 1/5 1 小时以内 新手友好度 88/100
microcks/microcks-cli#598 · 2 条评论 ·
维护者通常 1 天内回复
查看 microcks/microcks-cli 的全部 Issue
相似的 Issue
-
agent-butler-finding bug
难度 2/5 1-3 小时 新手友好度 82/100
jordansmall/spindrift#6414 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
Icinga/icinga-kubernetes#294 ·
维护者通常 4 天内回复
-
kind/design sig/ui
难度 1/5 1 小时以内 新手友好度 92/100
kubermatic/dashboard#8449 ·
维护者通常 1 天内回复
-
needs-triage
难度 2/5 1-3 小时 新手友好度 62/100
cli/cli#14962 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
model-drift
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复