{"record":{"id":"bca95f2488a6748a","repo":"multica-ai/multica","slug":"max-concurrent-tasks-must-be-0-got-d","errorCode":null,"errorMessage":"max_concurrent_tasks must be >= 0 (got %d)","messagePattern":"max_concurrent_tasks must be >= 0 \\(got (.+?)\\)","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"error","filePath":"server/cmd/multica/cmd_config.go","lineNumber":186,"sourceCode":"\t\t\tcfg.WorkspacesRoot = \"\"\n\t\t\treturn nil\n\t\t}\n\t\troot, err := filepath.Abs(value)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(\"resolve workspaces_root: %w\", err)\n\t\t}\n\t\tcfg.WorkspacesRoot = root\n\tcase \"max_concurrent_tasks\":\n\t\tif value == \"\" {\n\t\t\tcfg.MaxConcurrentTasks = 0\n\t\t\treturn nil\n\t\t}\n\t\tn, err := strconv.Atoi(value)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(\"max_concurrent_tasks must be an integer: %w\", err)\n\t\t}\n\t\tif n < 0 {\n\t\t\treturn fmt.Errorf(\"max_concurrent_tasks must be >= 0 (got %d)\", n)\n\t\t}\n\t\tcfg.MaxConcurrentTasks = n\n\tcase \"poll_interval\":\n\t\tif value == \"\" {\n\t\t\tcfg.PollInterval = \"\"\n\t\t\treturn nil\n\t\t}\n\t\td, err := time.ParseDuration(value)\n\t\tif err != nil {\n\t\t\treturn fmt.Errorf(\"poll_interval must be a Go duration (e.g. 10s, 500ms): %w\", err)\n\t\t}\n\t\t// Reject zero and negative durations. Persisting \"0s\" would look\n\t\t// configured in `config show` but be silently ignored at daemon\n\t\t// start (the resolver only substitutes strictly positive values),\n\t\t// which is exactly the trap reported in #3824's review. Empty\n\t\t// string is the one and only way to clear a previously persisted\n\t\t// value.\n\t\tif d <= 0 {","sourceCodeStart":168,"sourceCodeEnd":204,"githubUrl":"https://github.com/multica-ai/multica/blob/2c0912b6ec764b373d44eeea1e80f0d9f11ab417/server/cmd/multica/cmd_config.go#L168-L204","documentation":"After parsing max_concurrent_tasks as an integer, applyConfigSet enforces a non-negative lower bound. A negative integer (e.g. -1) parses fine but is rejected because a negative concurrency cap is meaningless for the daemon.","triggerScenarios":"`multica config set max_concurrent_tasks -1` or `-5`, often from shell arithmetic that subtracts (e.g. $TOTAL - $RESERVED going below zero).","commonSituations":"Computed values in scripts going negative when inputs shrink; '-1 = unlimited' conventions from other tools mistakenly applied here.","solutions":["Set a value >= 0 (0 disables the cap / means unset in this config's semantics).","Fix the script arithmetic that produced the negative number (clamp with a max/abs guard)."],"exampleFix":"# before\nmultica config set max_concurrent_tasks \"$(( TOTAL - RESERVED ))\"  # can go negative\n# after\nmultica config set max_concurrent_tasks \"$(( TOTAL - RESERVED > 0 ? TOTAL - RESERVED : 0 ))\"","handlingStrategy":"validation","validationCode":"# clamp before setting\nVAL=$(( VAL < 0 ? 0 : VAL ))\nmultica config set max_concurrent_tasks \"$VAL\"","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Clamp computed concurrency values at the source (max(value,0)).","Remember -1 does not mean unlimited in this CLI — never port that convention from other tools."],"tags":["cli","config","validation","go"],"backgroundTag":null,"analyzedSha":"2c0912b6ec764b373d44eeea1e80f0d9f11ab417","analyzedAt":"2026-08-15T13:25:18.241Z","schemaVersion":2},"datasetVersion":"2026-08-15T17:31:12.345Z"}