memmy-agent 启动成功后健康检查持续返回 503

[Memtensor-AI]

问题现象

执行 memmy-agent start 后命令显示启动成功，但健康检查持续返回 503；重启后仍可稳定复现。

预期行为

健康检查应返回 200。

实际行为

健康检查持续返回 503。

复现信息

• 组件：memmy-agent
• 复现方式：执行启动命令后进行健康检查
• 稳定性：重启后仍然复现
• trace_id: 5e4c99084dc8443dc12e39db7fb213f5
• xiaoyi: 3019ff20779d714c51a9c906
• issue: 49e2e5f41b0ddf6e325738e7

备注

知识库结果为 NO_REPLY，当前记录未提供运行环境、版本号或日志截图，但问题现象与期望/实际差异已足够明确。

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: 84031df2173cab4f
Working branch: bugfix/autodev-2340-20260903041102110
Target branch: latest dev* branch
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.

[Memtensor-AI]

🤔 AutoDev task 84031df2173cab4f needs clarification to proceed:
The issue names a component called "memmy-agent" and a startup command memmy-agent start, but neither can be located in the MemOS repository. Before fixing this bug, please clarify:

1. Which component are you actually running? A full-text search for "memmy" across the repo returns zero matches. Candidates that DO exist and expose a health check:
   (a) The FastAPI service memos.api.start_api:app started via make serve — has GET /health at src/memos/api/server_api.py:53 and src/memos/api/server_api_ext.py:121.
   (b) The TypeScript runtime under apps/memos-local-plugin/ — has GET /api/v1/health at apps/memos-local-plugin/server/routes/health.ts.
   (c) The MCP server bundled inside src/memos/api/.
   (d) The src/memos/mem_agent/ module (contains deepsearch_agent.py only — no HTTP server, no start command).

2. What is the exact memmy-agent start command line? The Python CLI memos (src/memos/cli.py) only defines download_examples and export_openapi; there is no start subcommand. Is "memmy-agent" perhaps an internal alias, wrapper script, or an alternative CLI from a downstream fork/deployment that we do not have visibility into?

3. Could you attach process logs from startup up through the failing health check? The ticket says startup succeeds and health returns 503, but no logs, no version, and no runtime environment are attached. The 503 status codes that this codebase actually emits come from src/memos/api/handlers/scheduler_handler.py:287,305 (scheduler queue unavailable / not connected to Redis) and src/memos/api/routers/server_router.py:280,295,310,459 (chat handler not initialized) — none of these are on /health. Logs would tell us which of these fired, or whether an infrastructure layer above the app (load balancer, gateway, ingress readiness probe) is emitting the 503.

4. Which branch / commit / release is the failing environment running? Confirming the branch narrows the scope: dev-v2.0.33 (this task's base), a tagged release, or a downstream branch.

Reply on this issue with /autodev confirm yes <your answers> — or /autodev confirm no <corrections> if the assumption below is wrong.
Suggested default assumption: If clarification is not available, assume "memmy-agent" is the FastAPI service memos.api.start_api:app (started by make serve), since its GET /health route matches the ticket shape most closely. Under that assumption we would investigate whether an upstream reverse proxy or a downstream dependency (Redis for scheduler, DB for user store) is degrading readiness in a way that turns /health into a 503. Note: /health currently hard-codes a 200 healthy response and does NOT probe dependencies, so any 503 must come from a layer above the app (e.g. an ingress readiness probe that expects a stricter contract, or the load balancer). Recommended follow-up if that is indeed the target: add a real dependency-aware readiness probe on /health and document its contract in the OpenAPI spec.
The suggested default is only used if a maintainer explicitly confirms it.
Please reply with one of the following commands (only issue author or repo collaborators):

• /autodev confirm yes — agree and continue with the suggested default assumption
• /autodev confirm no <additional info> — provide more details
• /autodev cancel — cancel this task
  If there is no reply within 24h, AutoDev will cancel this task using the same outcome as /autodev cancel. It will not continue with the suggested default automatically.

[Memtensor-AI]

⏰ AutoDev task 84031df2173cab4f received no /autodev confirm reply within 24h. AutoDev cancelled this task using the same outcome as /autodev cancel; it will not continue with the suggested default automatically.