daemon.autoindex.skipped omits the effective auto_index_limit

[rarepops]

Version

Current main at commit 010569fa6ce1bc5d6430f858129243ea1a2e3fd5 (built from source).

Platform

Windows (x64). The defect is in platform-independent daemon application logging.

Install channel

Built from source.

Binary variant

standard

What happened, and what did you expect?

When daemon-backed automatic indexing skips a repository because its tracked-file count exceeds auto_index_limit, the durable daemon.autoindex.skipped warning reports the tracked-file count but omits the effective configured limit.

The daemon already reads auto_index_limit into auto_index_limit and uses that value for the admission decision. I expected the warning to include the same value as a limit field, matching the diagnostic contract of the sibling MCP autoindex.skip event:

level=warn msg=daemon.autoindex.skipped project=<project> reason=too_many_files files=1 limit=0

Current event shape:

level=warn msg=daemon.autoindex.skipped project=<project> reason=too_many_files files=1

Without limit, the durable daemon log explains how many files were found but not which configured threshold caused the skip.

This is the daemon-log parity gap identified separately from #1466 and PR #1779. The maintainer requested that it remain a focused follow-up issue in #1779 (comment).

Reproduction

Current main already has a binding daemon application test that drives the affected path:

1. Build current main.

2. Run:

   make -f Makefile.cbm test-focused TEST_SUITES=daemon_application

3. In daemon_application_auto_index_honors_tracked_file_limit, the fixture creates a disposable Git repository containing one tracked file, uses an isolated cache, sets auto_index=true, sets auto_index_limit=0, and initializes a full-profile daemon application session.

4. The test confirms that the configured limit prevents worker admission. The warning emitted by that same branch is constructed in application_background_initialize_impl() as:

   cbm_log_warn(daemon.autoindex.skipped, project, project, reason,
                tracked_files >= 0 ? too_many_files : unsafe_or_unavailable_path, files,
                files);

5. Observe that auto_index_limit is available in the same scope and controls cbm_mcp_auto_index_within_file_limit(), but is not included in the warning.

Expected: the warning includes limit=<effective auto_index_limit>.

Actual: the warning ends after files=<tracked_files>.

Logs

level=warn msg=daemon.autoindex.skipped project=<project> reason=too_many_files files=1

Expected field parity:

level=warn msg=daemon.autoindex.skipped project=<project> reason=too_many_files files=1 limit=0

Diagnostics trajectory (memory / performance / leak issues)

Not applicable. This is a deterministic logging defect.

Project scale (if relevant)

One tracked file with auto_index_limit=0.

Confirmations

• I searched open and closed issues for daemon.autoindex.skipped, daemon auto-index limits, and daemon log parity. This is not a duplicate.
• The reproduction uses the repository's disposable test fixture and no proprietary code or logs.

[rarepops]

Confirmed against the current checkout with the repository test image:

$ ./build/c/test-runner daemon_application
daemon_application_auto_index_honors_tracked_file_limit
level=warn msg=daemon.autoindex.skipped project=tmp-cbm-app-auto-limit-root-<suffix> reason=too_many_files files=1
PASS

49 passed

The binding test passes because the skip decision is correct; the reproduced defect is specifically the missing limit=0 field in that warning.