Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

fix(services): 扩展服务启动器缺 logging 配置——delay/schedule/approval/callback/queue 全域静默（flow_worker 有先例，P2-6 漏修）

Open Beginner friendly
  • Is something wrong?
#46 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
92/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
observability

Research direction

Start by comparing plaita/server/services/main.py main() (line 38) with the existing fix in plaita/server/flow_worker.py:2639-2645, which already shows the exact logging.basicConfig line to mirror (level from PLAITA_LOG_LEVEL, default INFO). Add the same call as the first line of main() in the services launcher, without touching plaita/logger.py. Verify by running e.g. python -m plaita.server.services delay_service and confirming INFO startup lines on stdout, then checking PLAITA_LOG_LEVEL=DEBUG and running the existing test suite.

Written by the indexing model from the issue text.

Description

优先级 P3 · 依赖：无

基线 HEAD = f5e0c04

Summary

  • plaita/server/services/__main__.py（扩展服务统一启动器）全文无 logging 配置：零 import logging、零 logging.basicConfig（grep 反证：git show origin/main:plaita/server/services/__main__.py | grep -n "logging\." → 零命中），但 main()（:38）里大量调用 logger.info/error——:55「连接 Redis」、:61「Redis 连接成功」、:116「启动服务」、:122「服务已启动」、:133「服务已停止」。
  • plaita/logger.py:1-23 的库策略（原文注释）：只挂 NullHandler、不加强制 level、输出交由应用配置 ⇒ 经该启动器运行的 delay_service / schedule_service / approval_service / http_callback_service / redis_queue_service 全部零日志输出。
  • 同一问题有先例且已修：plaita/server/flow_worker.py:2639-2645 的 main() 首行即
    logging.basicConfig(level=os.environ.get("PLAITA_LOG_LEVEL", "INFO"), format="%(asctime)s %(levelname)s %(name)s: %(message)s")，
    注释明写「库内 logger 无 handler，原样跑运维看到的是零输出（2026-09 分布式评审 P2-6）」——同一问题在扩展服务启动器上漏修。
  • 复现（零依赖，已实测）：python -c "from plaita.logger import logger; import logging; print(logger.handlers, logging.root.handlers)" → [<NullHandler (NOTSET)>] []；再起任一扩展服务（如 python -m plaita.server.services delay_service）→ stdout/日志文件零输出。
  • 运维实证（2026-10-07 晚）：远端 systemd 起 python -m plaita.server.services schedule_service 后日志文件 0 字节；现用 python -c 包装器先配 logging 再进 launcher 规避。

影响

  • 扩展服务（延迟/调度/审批/回调/队列）静默运行：启动失败、Redis 连不上、任务处理异常在日志里全部不可见——运维只能靠 systemd 状态猜；10-07 晚调度服务接线即因此先踩了一轮（包装器规避）。
  • 与 flow_worker 不对称：同一库、同一条库策略，worker 有注释+修法，扩展服务没有——按 P2-6 的结论这是漏修而非设计取舍。

建议

  1. plaita/server/services/__main__.py 的 main()（:38）首行加与 flow_worker 同款的 logging.basicConfig(...)（level 取 PLAITA_LOG_LEVEL 缺省 INFO，format 同字符串）。
  2. 验收条件（可执行）：
    • 本地起任一扩展服务（python -m plaita.server.services delay_service --redis-url redis://…）→ stdout 即见 INFO 行（「启动服务: …」「服务 … 已启动」）；
    • PLAITA_LOG_LEVEL=DEBUG 生效、不设=INFO；
    • 三服务冒烟（delay/schedule/callback）均可见启动日志；既有测试全绿。

边界

  • 不改 plaita/logger.py 的库策略（NullHandler 是正确约定；修点在应用入口，不在库）。
  • 不加新依赖、不做日志落盘改造（systemd/容器侧负责收集）。
Dominant language
Python
Stars
0
Forks
1
Avg merge
1h 44m
Merged PRs (30d)
7

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from jeffkit/plaita

All issues in jeffkit/plaita

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.