Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/lumino-mcp-server/issues.md or /mcp/lumino-mcp-server/issues.json, or Pod over MCP.

Reported issues for Lumino MCP Server

Pod holds 19 of 103 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to Lumino MCP Server.

Most discussed

BUG: ci_cd_performance_baselining_tool — Prometheus queries missing k8s API params

Bug

All 10 Prometheus queries in ci_cd_performance_baselining_tool call _execute_prometheus_query_internal(query) without passing k8s_core_api or k8s_custom_api. The function needs these for endpoint discovery, causing "Could not discover Prometheus/Thanos endpoint" on every call. The tool returns empty data for all tests.

Fix

Pass the k8s API clients to each query call:

_execute_prometheus_query_internal(query, k8s_core_api=k8s_core_api, k8s_custom_api=k8s_custom_api)

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/47) · 2026-06-20 · closed · 1 comment

### BUG: find_pipeline crashes with 'coroutine is not iterable' — run_in_executor wraps async functions

## Bug

`find_pipeline()` in `src/server-mcp.py` passes `async def` functions to `loop.run_in_executor()` which expects sync callables. This returns unawaited coroutine objects, causing `argument of type 'coroutine' is not a container or iterable` when the code checks `"error" in result`.

**6 affected calls** (all in find_pipeline):
- `loop.run_in_executor(executor, fetch_pipelineruns_namespaced, ns)`
- `loop.run_in_executor(executor, fetch_taskruns_namespaced, ns)`
- `loop.run_in_executor(exec

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/43) · 2026-06-20 · closed · 1 comment

### 🔴 [Critical] Fabricated metrics returned as real data in `correlate_with_metrics`

## Bug Report

### Severity
🔴 **Critical** — Data Integrity Violation

---

### Summary

In `src/helpers/event_analysis.py`, the function `correlate_with_metrics` was using `random.uniform()` to **generate fake CPU, memory, and network metrics** and returning them to callers as if they were real, live Kubernetes metrics. This means LLM clients and SRE engineers were making operational decisions based on entirely fabricated data — with no indication that the values were synthetic.

---

### Affec

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/39) · 2026-04-03 · closed · 1 comment

### [LOW] find_pipeline takes 80+ seconds on large clusters due to unbounded cluster-wide LIST

## Summary

`find_pipeline` takes 80+ seconds on production clusters with 500+ namespaces. The tool performs cluster-wide LIST operations for PipelineRuns (limit=200) and Repositories (limit=500) across all namespaces, then does sequential substring matching against all returned items.

## Observed Timing

- **stone-prod-p02** (500+ namespaces): 83.4 seconds for pattern "build"
- Compare to median of ~13s for other tools on the same cluster

## Root Cause

`server-mcp.py` (line ~3615-3622) issue

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/160) · 2026-07-08 · open · 0 comments

### [MEDIUM] conservative_namespace_overview misclassifies INFO-level JSON logs as critical issues

## Summary

`conservative_namespace_overview` reports INFO-level structured JSON log lines as "critical issues". An `info`-level log entry like `{"level":"info","ts":"2026-07-08T06:50:02Z","msg":"reconciliation complete"}` is flagged as a critical finding when its message text happens to contain error-related keywords.

## Root Cause

Two compounding issues:

### 1. Timestamp regex in `_get_structured_log_level()` doesn't handle timezone offsets

`log_analysis.py` (line ~354) uses this regex to 

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/159) · 2026-07-08 · open · 0 comments

### [MEDIUM] KubeArchive auth header doubled when k8s client stores Bearer prefix with different casing

## Summary

`query_kubearchive` returns HTTP 400: `"incorrectly formatted authorization header, expected two strings separated by a space but found 3"`. The auth header sent to KubeArchive contains a doubled prefix like `Bearer bearer sha256~token` (3 space-separated parts instead of 2).

## Root Cause

`_extract_token_from_client()` in `kubearchive_integration.py` (line ~748) uses a **case-sensitive** `startswith("Bearer ")` check to strip an existing prefix from the k8s client's `api_key`. If 

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/158) · 2026-07-08 · closed · 0 comments

### [MEDIUM] Inconsistent tool count across README and server.json

## File and Location

- **README.md**, line 35 (and lines 520, 954)
- **server.json**, line 5

## Description

The tool count is stated inconsistently across multiple documentation sources:

| Source | Claim | Actual |
|--------|-------|--------|
| `README.md` line 35 | "37 specialized tools" | Incorrect |
| `README.md` line 520 | "MCP server with all 37 tools" | Incorrect |
| `README.md` line 954 | "Available tools: 37" | Incorrect |
| `server.json` line 5 | "40+ Tekton debugging tools" | Incor

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/146) · 2026-06-23 · open · 0 comments

### [LOW] Tunable configuration thresholds lack documentation of purpose and valid ranges

## Location

**File:** `src/helpers/constants.py`
**Line:** 15 (and continuing through line 136)

## Description

The configuration dictionaries `SMART_EVENTS_CONFIG`, `LOG_ANALYSIS_CONFIG`, and `PIPELINE_ANALYSIS_CONFIG` contain numerous tunable thresholds that lack documentation explaining their purpose, units, valid ranges, or performance implications.

Specific undocumented thresholds include:

- **`SMART_EVENTS_CONFIG.defaults`** (line 16-22): `max_events_auto`, `max_events_raw`, `token_thr

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/145) · 2026-06-23 · open · 0 comments

## Most recent

### [LOW] Container user belongs to GID 0 (root group)

## File

`Containerfile`, line 47

```dockerfile
RUN useradd --uid 1001 --gid 0 --shell /bin/bash --create-home lumino && \
    mkdir -p /opt/app-root/src && \
    chown -R 1001:0 /opt/app-root && \
    chmod -R g+rwX /opt/app-root

Description

The lumino user is created with --gid 0, placing it in the root group. While this is standard OpenShift practice for arbitrary UID support (OpenShift assigns random UIDs that must still function, and GID 0 membership is the conventional way to

Read the thread · 2026-06-23 · open · 0 comments

[LOW] convert_duration_to_seconds/hours only support 3 input values but docs don't say so

File

src/helpers/utils.py, lines 2125–2134

Description

convert_duration_to_seconds() and convert_duration_to_hours() only support three hardcoded input values — "1h", "24h", and "7d" — via a dictionary lookup. Any other input silently returns the default value (86400 seconds or 24 hours) without any warning or error.

The docstrings currently read:

def convert_duration_to_seconds(duration: str) -> int:
    """Convert duration string to seconds."""
    duration

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/143) · 2026-06-23 · open · 0 comments

### [LOW] Duplicate parse_time_period() in utils.py and ml_persistence.py

## File Paths and Lines

- `src/helpers/utils.py` — line 141
- `src/helpers/ml_persistence.py` — line 1478
- `src/helpers/__init__.py` — lines 6 and 241

## Description

`parse_time_period()` is defined in two separate modules with slightly different implementations:

1. **`utils.py:141`** — Uses a regex pattern (`r'^(\d+)([smhd])$'`) for strict validation. Supports seconds (`s`), minutes (`m`), hours (`h`), and days (`d`). Raises `ValueError` on invalid input.

2. **`ml_persistence.py:1478`** —

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/142) · 2026-06-23 · open · 0 comments

### [LOW] AnalysisCache class lacks documentation of expiry, eviction, and thread-safety

## File

`src/helpers/log_analysis.py`, line 50

## Description

The `AnalysisCache` class docstring on line 51 reads only:

Simple in-memory cache for analysis results.


This does not document three important behavioral characteristics that a caller or maintainer needs to know:

1. **Cache expiry**: Entries expire after 10 minutes (600 seconds), as implemented in the `get()` method at line 70. A caller has no way to know this without reading the source.

2. **Eviction strategy**: When t

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/140) · 2026-06-23 · open · 0 comments

### [LOW] Architecture tree omits 2 helper modules

## File

`README.md`, line 520 (Architecture section, lines 516-530)

## Description

The architecture tree in the README shows the `helpers/` subpackage with only 6 modules:

└── helpers/ ├── constants.py ├── event_analysis.py ├── failure_analysis.py ├── log_analysis.py ├── resource_topology.py ├── semantic_search.py └── utils.py


However, the actual `src/helpers/` directory contains 8 modules (plus `__init__.py`). The two missing entries are:

- **`ml_persis

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/137) · 2026-06-23 · open · 0 comments

### [LOW] CPU detection heuristic may misidentify memory values

## File

`src/helpers/utils.py`, line 734

## Description

The `is_cpu` heuristic at line 734 determines whether a resource value represents CPU or memory based on simple pattern matching:

```python
is_cpu = used.endswith('m') or limit.endswith('m') or (
    used.count('.') > 0 and used[-1].isdigit())

The third condition (used.count('.') > 0 and used[-1].isdigit()) treats any value containing a decimal point and ending with a digit as a CPU value. However, a memory value like '1.5' (wi

Read the thread · 2026-06-23 · open · 0 comments

[LOW] Exception silently swallowed in get_current_cluster_id with no debug logging

Location

File: src/helpers/ml_persistence.py Line: 57

Description

In the get_current_cluster_id function, the second except Exception block (line 57) silently swallows all exceptions with a bare pass statement. This is the fallback path that attempts to detect an in-cluster Kubernetes configuration via the KUBERNETES_SERVICE_HOST environment variable.

# Fallback: try to get from in-cluster config
try:
    import os
    # In-cluster, use the API server from e

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/134) · 2026-06-23 · closed · 0 comments

### [LOW] 289 lines of dead code from commented-out MCP tools

## File

`src/server-mcp.py`

## Location

- `get_konflux_components_status`: lines 2455-2605 (150 lines)
- `track_pipeline_across_namespaces`: lines 2969-3108 (139 lines)

## Description

Two MCP tools remain in the codebase with their full function bodies intact but their `@mcp.tool()` decorators commented out:

```python
# @mcp.tool()  # Commented out - Konflux-specific tool
async def get_konflux_components_status() -> Dict[str, Any]:
    ...

# @mcp.tool()  # Commented out - Ko

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/133) · 2026-06-23 · open · 0 comments

### [LOW] Redundant imports inside function body already imported at module level

## Location

**File:** `src/server-mcp.py`
**Lines:** 253, 280

## Description

The `log_tool_execution` decorator contains imports inside the function body that are redundant or misplaced:

- **Line 280:** `import asyncio` is redundant — `asyncio` is already imported at module level (line 14).
- **Line 253:** `import functools` is placed inside the function body rather than at module level, which is inconsistent with the rest of the file's import style.

While Python caches module imports so th

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/132) · 2026-06-23 · open · 0 comments

### [LOW] get_kubernetes_resource is sync while all other MCP tools are async

## File

`src/server-mcp.py`, line 1097

## Description

`get_kubernetes_resource` is defined as a synchronous function (`def`) while every other `@mcp.tool()` function in the file is defined as asynchronous (`async def`). If the MCP framework dispatches tool handlers on the event loop thread, this synchronous function will block the entire event loop for the duration of its Kubernetes API calls.

This is distinct from #117 (which covers blocking synchronous K8s API calls *inside* `async def` fu

[Read the thread](https://github.com/spre-sre/lumino-mcp-server/issues/131) · 2026-06-23 · closed · 0 comments

### [LOW] SQLite connections not closed in error paths

## File

`src/helpers/ml_persistence.py`, line 353 (and multiple callers of `_get_connection`)

## Description

`TrainingDataStore._get_connection()` (line 462) returns a raw `sqlite3.Connection` that callers must manually close. Throughout the file, methods follow the pattern:

```python
conn = self._get_connection()
# ... operations that may raise ...
conn.close()

If an exception occurs between the _get_connection() call and the explicit conn.close(), the connection is leaked. This af

Read the thread · 2026-06-23 · closed · 0 comments

The remaining reports are on the project's issue tracker.