autoindex.skip logs the config key instead of the numeric auto_index_limit

[Tomauskasz]

Version

codebase-memory-mcp 0.9.0

Platform

macOS, Apple Silicon

Install channel

GitHub release archive via install.sh

Binary variant

ui

What happened, and what did you expect?

When automatic indexing skips a repository because its tracked-file count exceeds auto_index_limit, the warning logs the configuration key name instead of the configured numeric limit.

The skip decision is correct. With two tracked files and auto_index_limit=1, v0.9.0 logs:

level=warn msg=autoindex.skip reason=too_many_files files=_______2_ limit=auto_index_limit

I expected the limit field to contain the effective configured value:

level=warn msg=autoindex.skip reason=too_many_files files=2 limit=1

The malformed files field shown by v0.9.0 is not the focus of this report: current main already formats that count as an integer string. The limit field still uses the key name on current main.

Reproduction

This uses only a disposable dummy repository and an isolated cache:

repro_dir="$(mktemp -d)"
mkdir "$repro_dir/repo"
cd "$repro_dir/repo"
git init -q
printf 'one\n' > one.txt
printf 'two\n' > two.txt
git add one.txt two.txt
git -c user.name=Repro -c user.email=repro@example.invalid commit -qm initial

CBM_CACHE_DIR="$repro_dir/cache" codebase-memory-mcp config set auto_index true
CBM_CACHE_DIR="$repro_dir/cache" codebase-memory-mcp config set auto_index_limit 1

printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"autoindex-limit-repro","version":"1.0"}}}' \
  | CBM_CACHE_DIR="$repro_dir/cache" codebase-memory-mcp 2>server.log

grep 'msg=autoindex.skip' server.log

Relevant logs

level=warn msg=autoindex.skip reason=too_many_files files=_______2_ limit=auto_index_limit

Source evidence

In v0.9.0, src/mcp/mcp.c passes the configuration key constant to the logger:

cbm_log_warn("autoindex.skip", "reason", "too_many_files", "files", line, "limit",
             CBM_CONFIG_AUTO_INDEX_LIMIT);

Current main at commit 0d6f26a1708c1e1f0e6a59867bee4bee3fe076b5 corrects the file-count conversion, but still passes the same key-name constant:

char files[32];
(void)snprintf(files, sizeof(files), "%d", file_count);
cbm_log_warn("autoindex.skip", "reason",
             file_count >= 0 ? "too_many_files" : "unsafe_or_unavailable_path", "files",
             files, "limit", CBM_CONFIG_AUTO_INDEX_LIMIT);

The effective file_limit value is already available in this scope. Formatting it as a decimal string for the limit field would make this diagnostic actionable.

Diagnostics trajectory

Not applicable. This is a deterministic logging defect, not a performance or memory problem.

Project scale

Two tracked files with auto_index_limit=1.

Confirmations

• I searched existing issues and inspected the related auto-index reports; none cover this diagnostic defect.
• The reproduction uses only a disposable dummy repository and contains no proprietary code or logs.

[DeusData]

Fixed on main by dc24d581 ("fix(mcp): log the numeric auto_index_limit in autoindex.skip"), merged as b44e5849 via #1779. Thanks to @rarepops.

The warning now reports the effective limit:

level=warn msg=autoindex.skip reason=too_many_files files=2 limit=1

src/mcp/mcp.c was passing CBM_CONFIG_AUTO_INDEX_LIMIT — the #defined config key name — as the value of the limit field, while the numeric file_limit was already in scope a few lines above. It is now formatted into a buffer the same way the neighbouring files count already was, so the two adjacent fields follow one convention.

Covered by autoindex_skip_reports_numeric_limit_issue1466 in tests/test_mcp.c, which drives the real initialize → maybe_auto_index path against a project exceeding auto_index_limit and captures the emitted warning through a log sink.