fix(memory): raise curation LLM timeout default from 10s to 60s#1679
Merged
Aaronontheweb merged 1 commit intoJul 16, 2026
Conversation
Aaronontheweb
merged commit Jul 16, 2026
3aa5617
into
netclaw-dev:feature/memory-embeddings
15 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Canary (0.25.0-alpha.onnx.7) doctor report: Memory Curation LLM failure rate 46% (11/24) in the last 14 days. Log forensics confirm 100% of those failures are
curation_llm_timeoutevents — zero parse errors, zero exceptions. The curation LLM synthesizes merged memory bodies withLlmMaxOutputTokens = 4096; the previous 10sLlmTimeoutSecondsceiling isn't enough for that much output on real providers. Curation is background quality work where success matters far more than latency.Fix
Raise
MemoryCurationConfig.LlmTimeoutSecondsdefault from 10s to 60s (src/Netclaw.Configuration/MemoryConfig.cs). Also addedtimeoutSecondsto thecuration_llm_timeoutwarning log so future investigations don't have to infer the configured ceiling.Schema sync
LlmTimeoutSecondsis bound at runtime from thenetclaw.json"Memory"section viaconfiguration.GetSection("Memory").Get<MemoryConfig>()(src/Netclaw.Daemon/Program.cs), registered as a DI singleton, and flows intoMemoryCurationEvaluator.TryLlmEvaluationAsyncthroughMemoryCurationConfig— not code-only. Updated thedefaultinsrc/Netclaw.Configuration/Schemas/netclaw-config.v1.schema.json(10 → 60) in the same commit per the Configuration Schema Sync Rule.Tests
Updated the bear-trap default-pinning test (
MemoryConfigDefaultsTests.Curation_llm_timeout_seconds_defaults_to_60, was_defaults_to_10). No new test added for the constant itself per repo testing guidelines (zero-logic trivia). No existing test exercises the actual timeout/cancellation path with a fake delay, so nothing else needed updating.Eval suite — intentionally skipped
Per CLAUDE.md, the eval suite (
./evals/run-evals.sh) is required for memory-pipeline changes. Skipping it here deliberately: it's an expensive external-API suite, and a timeout default isn't something it exercises (no eval case depends onLlmTimeoutSeconds). Flagging this as an explicit Definition-of-Done deviation rather than a silent skip.Gates run
dotnet build— 0 warnings, 0 errorsdotnet testNetclaw.Actors.Tests — 2756 passeddotnet testNetclaw.Configuration.Tests — 514 passeddotnet testNetclaw.Cli.Tests — 1334 passed (coversConfigSchemaDoctorCheckTests)dotnet slopwatch analyze— 0 issuespwsh ./scripts/Add-FileHeaders.ps1 -Verify— all files have headers