Files
Jamie Pineandcapy-ai-staging[bot] fc1798b05a Windows unit job gates main; daemon raises its fd limit; sd-version marker test (#3153)
* CI: the Windows unit job gates main

Core Tests (windows unit) was green twice on main (15d7df1, e4b4cb7), 40 min
cold and 21 min warm, so continue-on-error goes and the name loses its
caveat. cache-on-failure stays so a red run still warms the fix's run.

Co-authored-by: capy-ai-staging[bot] <305915985+capy-ai-staging[bot]@users.noreply.github.com>

* Daemon raises its own file descriptor limit at startup

The daemon shelled out to 'ulimit -n' to read the limit and warned when it
was under 10000, which it is at every launchd start on a Mac with a plist
written before #3111 (8192). Now it calls setrlimit: the hard limit when
finite, else 65536 then OPEN_MAX, since macOS reports unlimited but refuses
a soft limit above kern.maxfilesperproc. One info line records the result;
the warning stays only when the raise fails. The desktop app's LaunchAgent
template gains the same SoftResourceLimits NumberOfFiles 65536 the CLI's
already has.

Co-authored-by: capy-ai-staging[bot] <305915985+capy-ai-staging[bot]@users.noreply.github.com>

* sd update: version marker writer with a unit test

The updater already wrote sd-version.txt after an install (#3111). The write
moves into write_version_marker so a test can prove the format: the full sha
on one line with a trailing newline, as the rebuild script writes it.

Co-authored-by: capy-ai-staging[bot] <305915985+capy-ai-staging[bot]@users.noreply.github.com>

* Raise the fd limit before Core::new and warn when the raised limit is still low

Library pools, watchers and the network endpoint open descriptors inside
Core::new, so the raise has to come first. A raise that lands under 10000
(a container with hard 8192) now still warns.

Co-authored-by: capy-ai-staging[bot] <305915985+capy-ai-staging[bot]@users.noreply.github.com>

---------

Co-authored-by: capy-ai-staging[bot] <305915985+capy-ai-staging[bot]@users.noreply.github.com>
2026-10-09 13:22:00 +00:00
..