Skip to content

Conversation

@tisnik
Copy link
Contributor

@tisnik tisnik commented Sep 18, 2025

Description

LCORE-700: logging for info and health endpoints

Type of change

  • Refactor
  • New feature
  • Bug fix
  • CVE fix
  • Optimization
  • Documentation Update
  • Configuration Update
  • Bump-up service version
  • Bump-up dependent library
  • Bump-up library or tool used for development (does not change the final image)
  • CI configuration change
  • Konflux configuration change
  • Unit tests improvement
  • Integration tests improvement
  • End to end tests improvement

Related Tickets & Documents

  • Related Issue #LCORE-700

Summary by CodeRabbit

  • Chores
    • Enhanced observability for health and info endpoints by standardizing the logger namespace and adding informative logs for liveness, readiness, and info responses.
    • Added debug details for service name, service version, and Llama Stack version to aid diagnostics.
    • No changes to endpoint behavior, response formats, or error handling; APIs function as before.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Sep 18, 2025

Walkthrough

Logging namespaces were standardized and additional log statements were added across health and info endpoints. No endpoint logic, signatures, control flow, or error handling was changed. Observed behavior remains the same aside from added info/debug logs.

Changes

Cohort / File(s) Summary
Standardized logger namespace and added endpoint logs
src/app/endpoints/health.py, src/app/endpoints/info.py
Switched logger initialization from __name__ to "app.endpoints.handlers". Added info logs for /v1/readiness, /v1/liveness, and /v1/info responses. In info.py, added debug logs for service name, service version, and Llama Stack version. No control-flow or return-type changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

A nibble of logs, a hop through code,
Footprints in traces where endpoints strode.
Readiness rustles, liveness sings,
Info debugs with fluttering wings.
Carrots of context neatly aligned—
I thump in approval, tail bright and primed. 🥕🐇

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title "LCORE-700: logging for info and health endpoints" is concise and directly reflects the primary change in the diff — adding/refactoring logging for the info and health endpoints; it references the related ticket for traceability and avoids extraneous detail, so a reviewer scanning history can understand the main intent. The modified files (src/app/endpoints/info.py and health.py) and the PR objectives align with this description. Thus the title meets the stated criteria for clarity and relevance.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

  • Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
  • Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (4)
src/app/endpoints/info.py (3)

61-61: Demote request log to DEBUG or enrich with structured fields.

Info endpoint is low-traffic, but a bare INFO adds little value. Prefer DEBUG or include status/duration.

-    logger.info("Response to /v1/info endpoint")
+    logger.debug("GET /v1/info requested")

69-71: Fix typo in log and (optional) avoid repeated config lookups.

“LLama” → “Llama”. Optionally cache configuration once.

Apply:

-        logger.debug("LLama Stack version: %s", llama_stack_version)
+        logger.debug("Llama Stack version: %s", llama_stack_version)

Optional (outside changed lines):

cfg = configuration.configuration
logger.debug("Service name: %s", cfg.name)
# ... and use cfg.name in the response too

19-19: Use module-scoped loggers for endpoints.

Multiple endpoint modules currently share logger "app.endpoints.handlers"; use module-scoped names for per-endpoint tuning.

  • src/app/endpoints/info.py — logger = logging.getLogger("app.endpoints.info")
  • src/app/endpoints/health.py — logger = logging.getLogger("app.endpoints.health")
  • src/app/endpoints/root.py — logger = logging.getLogger("app.endpoints.root")
  • src/app/endpoints/conversations.py — logger = logging.getLogger("app.endpoints.conversations")
  • src/app/endpoints/query.py — logger = logging.getLogger("app.endpoints.query")
  • src/app/endpoints/streaming_query.py — logger = logging.getLogger("app.endpoints.streaming_query")

Keep src/utils/mcp_headers.py as logger = logging.getLogger("app.endpoints.dependencies").

src/app/endpoints/health.py (1)

25-25: Replace shared logger "app.endpoints.handlers" with module-scoped loggers

Use per-module names (e.g., "app.endpoints.health") so each endpoint can be filtered independently. Update the occurrences below:

  • src/app/endpoints/health.py
  • src/app/endpoints/info.py
  • src/app/endpoints/streaming_query.py
  • src/app/endpoints/query.py
  • src/app/endpoints/conversations.py
  • src/app/endpoints/root.py

Example diff (health.py):

-logger = logging.getLogger("app.endpoints.handlers")
+logger = logging.getLogger("app.endpoints.health")

src/utils/mcp_headers.py already uses "app.endpoints.dependencies" and can remain as-is.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ae0c2e6 and 92344d1.

📒 Files selected for processing (2)
  • src/app/endpoints/health.py (3 hunks)
  • src/app/endpoints/info.py (2 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
src/app/endpoints/info.py (2)
src/client.py (2)
  • AsyncLlamaStackClientHolder (18-55)
  • get_client (49-55)
src/configuration.py (1)
  • configuration (60-64)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: build-pr
  • GitHub Check: e2e_tests

# Used only for authorization
_ = auth

logger.info("Response to /v1/readiness endpoint")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue

Health endpoints: avoid high-volume INFO logs; demote and log outcomes instead.

These endpoints are hit frequently (Kubernetes probes); INFO here will flood logs. Use DEBUG for requests and WARNING/INFO once per failure/transition with fields.

Apply:

-    logger.info("Response to /v1/readiness endpoint")
+    logger.debug("GET /v1/readiness requested")
-    logger.info("Response to /v1/liveness endpoint")
+    logger.debug("GET /v1/liveness requested")

Then, add outcome logs near the decision (outside the changed lines):

# after computing ready/reason/unhealthy_provider_names, before return
if unhealthy_providers:
    logger.warning(
        "Readiness failed",
        extra={"ready": False, "reason": reason, "unhealthy": unhealthy_provider_names},
    )
else:
    logger.debug(
        "Readiness ok",
        extra={"ready": True, "reason": reason},
    )

Also applies to: 140-140

🤖 Prompt for AI Agents
In src/app/endpoints/health.py around lines 96 and 140, the health endpoint
currently emits high-volume INFO logs; change the logger.info calls on those
lines to logger.debug to avoid log flooding from frequent probes, and then add
outcome logs immediately after the readiness decision (after computing
ready/reason/unhealthy_provider_names) as described: if there are unhealthy
providers emit a logger.warning with extra={"ready": False, "reason": reason,
"unhealthy": unhealthy_provider_names}, otherwise emit a logger.debug with
extra={"ready": True, "reason": reason}. Ensure the new outcome logging is
placed outside the changed lines and uses the computed variables.

@tisnik tisnik merged commit 5eb2caa into lightspeed-core:main Sep 18, 2025
18 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant