[BUG] inspect_schema matches named container case-insensitively without preferring exact match

Aperta Adatta ai principianti
  • Qualcosa non va?
#2,128 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Maaz2212 ci sta già lavorando.

Dal 31/10/2026.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
88/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rabbitmq, typescript
Ambito
databases

Direzione di ricerca

Leggi src/lib/mcp/tools/inspect-schema.ts e i test esistenti in tests/unit/mcp/inspect-schema.test.ts. Aggiungi test per i container denominati Billing e billing, incluso il caso di fallback senza distinzione tra maiuscole e minuscole quando non esiste una corrispondenza esatta. Il lavoro è terminato quando vengono preferite le corrispondenze esatte e i test passano.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Description

When calling the MCP tool inspect_schema with a schema argument, chooseContainer performs a purely case-insensitive search (candidate.name.toLowerCase() === wanted) against the list of available containers.

On database engines and message brokers that support case-sensitive container names (for instance, RabbitMQ virtual hosts such as Billing and billing, or engines with case-sensitive schema names), requesting schema: "billing" will pick whichever container is returned first by listContainers(). If Billing appears first in the list, inspect_schema inspects Billing instead of the exact match billing.

Steps to Reproduce

  1. Configure a connection to an engine with case-sensitive container names (e.g., RabbitMQ with virtual hosts Billing and billing, where Billing is listed first).
  2. Invoke the MCP tool inspect_schema passing schema: "billing": 
    {
  "connection_id": "<connection_id>",
  "schema": "billing"
}
  3. Inspect the returned container in the response payload.
  4. Notice that inspect_schema chose the container Billing instead of the exact match billing.

Expected Behavior

chooseContainer should prioritize an exact case match (candidate.name === schema) first. It should only fall back to a case-insensitive match (candidate.name.toLowerCase() === wanted) when no exact match exists.

Actual Behavior

chooseContainer uses containers.find((candidate) => candidate.name.toLowerCase() === wanted) immediately. Whichever container appears earlier in the enumeration order is chosen, even when an exact case match exists later in the array.

Environment

  • LibreDB Studio Version: 1.2.0
  • Browser: All / Headless MCP
  • OS: macOS / Linux / Windows
  • Node.js/Bun Version: Bun 1.4.3 / Node.js 24
  • Database Type: RabbitMQ / PostgreSQL / case-sensitive container engines

Additional Context

Documented in docs/BACKLOG.md under item MCP3:

chooseContainer compares names lower-cased, so on a RabbitMQ broker with virtual hosts Billing and billing a call naming billing reads whichever is listed first; Kubernetes namespaces are lower case, so it never mattered before.

Done when: the chooser prefers an exact match and falls back to the case-insensitive one only when no exact match exists, for every provider, with a test on two names that differ by case.

Possible Solution

In src/lib/mcp/tools/inspect-schema.ts, update chooseContainer:

const chosen = named
  ? (containers.find((candidate) => candidate.name === schema) ??
     containers.find((candidate) => candidate.name.toLowerCase() === wanted))
  : (containers.find((candidate) => candidate.isSessionDefault === true) ?? containers[0]);

Add a test in tests/unit/mcp/inspect-schema.test.ts verifying that when containers ['Billing', 'billing'] are present, querying schema: "billing" selects billing, and querying schema: "BILLING" falls back to the first match when no exact match exists.

Lingua principale
TypeScript
Stelle
810
Fork
158
Merge medio
9h 47m
PR unite (30g)
590

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di libredb/libredb-studio

Tutte le issue di libredb/libredb-studio

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.