[gaurav0107]

What does this PR do?

Fixes #1818. When daemon-backed auto-indexing refuses a repository, daemon.autoindex.skipped in application_background_initialize_impl() (src/daemon/application.c) logged project, reason and files, but not the limit that caused the refusal. This adds limit=<effective auto_index_limit>, formatted the same way as the MCP autoindex.skip event from #1779. The value is the auto_index_limit the admission check cbm_mcp_auto_index_within_file_limit() already used. Admission behavior is unchanged, as you asked in the issue.

Before / after, from the binding test fixture (1 tracked file, auto_index_limit=0):

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

The field is also added on the unsafe_or_unavailable_path branch. It's the same log call, and the MCP event carries limit on both branches too.

Credit to @rarepops, who reported and confirmed this. You invited them to open the PR on Sep 26. Nothing had been opened four weeks later, so I picked it up. I'm happy to close this if they'd rather send their own.

Tests

daemon_application_auto_index_honors_tracked_file_limit in tests/test_daemon_application.c already drives this branch. It now installs a log sink around the initialize/admission wait and asserts that the captured daemon.autoindex.skipped line carries reason=too_many_files, files=1 and limit=0 as whole fields, so limit=00 would not match. The warning is emitted on the background-initialize thread before the release increment that app_wait_for_background_initializes() waits on. The sink publishes through an atomic_bool. The sink, level and format are restored before any assert.

Evidence

Machine: Amazon Linux 2023, x86_64, clang 15.0.7 (ASan+UBSan, default Makefile.cbm test flags).

make -f Makefile.cbm test-focused TEST_SUITES=daemon_application CC=clang CXX=clang++
  main + new test:  73 passed, 1 failed
                    daemon_application_auto_index_honors_tracked_file_limit FAIL
                    tests/test_daemon_application.c:3004:
                    ASSERT(app_log_line_has_field(app_autoindex_skipped_line, "limit=0"))
  this branch:      74 passed
build/c/test-runner mcp daemon_runtime daemon_application daemon_ipc   (this branch)
  0 FAIL
build/c/test-runner cli   (this branch)
  364 passed
scripts/check-dco.sh upstream/main..HEAD   OK

On main, the earlier assertions in the test (skip line captured, reason=too_many_files, files=1) pass. Only the limit=0 assertion fails.

Not verified locally

• scripts/lint.sh: cppcheck and clang-format-20 aren't installed here. git diff -U0 upstream/main..HEAD | clang-format-diff -p1 (clang-format 15) is empty. The lint CI job (cppcheck + clang-format-20) passed on this PR.
• I didn't run the full default scripts/test.sh venue run. I ran only the suites above.

Checklist

• Every commit is signed off (git commit -s): scripts/check-dco.sh upstream/main..HEAD OK
• Tests pass locally (make -f Makefile.cbm test): daemon_application, cli, mcp, daemon_runtime and daemon_ipc pass (see above); the full run was not done locally
• Lint passes (make -f Makefile.cbm lint-ci): not run locally; the lint CI job passed (see above)
• New behavior is covered by a test (reproduce-first for bug fixes)

---

🤖 Opened with Superhuman, an open-source contribution agent.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thanks again @gaurav0107 - this is a careful, focused fix for #1818. We merged current main into your branch (one signed-off merge commit, ca41963; your commit is unchanged) so CI can re-run against the latest daemon changes from #2737, which touched the same two files. No action needed, but please pull before pushing again. We will merge once the fresh checks are green.

[gaurav0107]

Thanks @DeusData, appreciate you merging main in. I've pulled ca41963 locally and will build on top of it if anything else is needed.

[DeusData]

Merged as e73eb9d - thank you, @gaurav0107! daemon.autoindex.skipped now logs the effective auto_index_limit, so it is clear why a project was skipped (fixes #1818). Thanks also to @rarepops for the original report.