Repository navigation
daemon.autoindex.skipped omits the effective auto_index_limit #1818
Description
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:
-
Build current
main. -
Run:
make -f Makefile.cbm test-focused TEST_SUITES=daemon_application
-
In
daemon_application_auto_index_honors_tracked_file_limit, the fixture creates a disposable Git repository containing one tracked file, uses an isolated cache, setsauto_index=true, setsauto_index_limit=0, and initializes a full-profile daemon application session. -
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);
-
Observe that
auto_index_limitis available in the same scope and controlscbm_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.
Activity
rarepops commentedon Aug 24, 2026
Confirmed against the current checkout with the repository test image:
The binding test passes because the skip decision is correct; the reproduced defect is specifically the missing
limit=0field in that warning.DeusData commentedon Sep 19, 2026
Thank you for the confirmation. Current main computes the effective
auto_index_limit, but thedaemon.autoindex.skippedevent insrc/daemon/application.crecords only project, reason, and file count. That confirms the diagnostic omission in the source. The focused change should report the effective limit alongside the count without changing admission behavior.DeusData commentedon Sep 26, 2026
Thank you for spotting this, @rarepops! You're right:
auto_index_limitis in scope at thedaemon.autoindex.skippedlog site (src/daemon/application.c around line 2080) but is never logged, so the line doesn't say which limit was hit. Since you know this area from #1779, would you like to open a small PR that adds thelimitfield? We'd be happy to review it quickly. Thanks again!