feat(dashboard): expose build timeout & insight extraction settings in the UI#1935
Conversation
…s UI Both settings already exist in the Settings schema and are honored by the engine, but neither had a control in the dashboard, so users could only change them by hand-editing config.json while the app was closed (the running app rewrites config.json from its DB, clobbering live file edits). - Add 'Build/Verification Timeout (minutes)' to the Scheduling section, next to the existing stuck-task timeout (same minutes<->ms conversion). - Add 'Enable Insight Extraction' + cron schedule to the Memory section, next to the existing auto-summarize controls. Both are placed in their existing project-scoped sections. Follow-up: a global-defaults counterpart could be added if maintainers want these settable at the user/global level too.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds two independent settings UI additions: an “Enable Insight Extraction” checkbox with conditional cron schedule input in MemorySection, and a “Build/Verification Timeout (minutes)” number input in SchedulingSection that converts between minutes and milliseconds via form state. ChangesSettings Form Additions
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR exposes existing project settings in the dashboard UI. The main changes are:
Confidence Score: 4/5The build timeout UI needs a runtime wiring fix before merging.
packages/dashboard/app/components/settings/sections/SchedulingSection.tsx Important Files Changed
Reviews (1): Last reviewed commit: "feat(dashboard): expose build timeout & ..." | Re-trigger Greptile |
| <input id="buildTimeoutMs" type="number" min={1} step={1} value={form.buildTimeoutMs ? Math.round(form.buildTimeoutMs / 60000) : ""} onChange={(e) => { | ||
| const val = e.target.value; | ||
| const num = Number(val); | ||
| setForm((f) => ({ ...f, buildTimeoutMs: val && num > 0 ? num * 60000 : undefined })); | ||
| }}/> | ||
| <small>{t("settings.scheduling.maximumTimeInMinutesForBuildVerificationCommands", "Maximum time in minutes for build/verification commands before they are killed. Raise for large monorepo or Docker builds. Default: 5.")}</small> |
There was a problem hiding this comment.
Timeout Control Has No Consumer
Changing this field persists buildTimeoutMs, but the runtime command path does not read that setting when applying build or verification timeouts. An operator can raise the value for a long monorepo or Docker build, see the setting save, and still have the build killed at the existing timeout.
Problem
Two settings that already exist in the
Settingsschema and are honored by the engine have no control anywhere in the dashboard UI:buildTimeoutMs— max time for build/verification commands (default300000= 5 min)insightExtractionEnabled(+insightExtractionSchedule) — periodic extraction of durable insights from completed tasks into memoryBecause there's no UI, the only way to change them is to hand-edit
config.json— but that has to be done with the app fully closed, since the running app rewritesconfig.jsonfrom its database on reload/shutdown and silently clobbers live file edits. That's a confusing footgun (edits appear to "not stick"), and 5 minutes is too low a build timeout for large monorepo / Docker builds.Change
Expose both via controls that mirror the existing patterns in the same sections — no schema, route, or persistence changes needed (the keys already flow through
form/setForm→updateSettings).insightExtractionScheduleis already documented intypes.ts).Both use the existing
t(...)i18n fallback style used throughout these sections.Scope note (feedback welcome)
Both live in their existing project-scoped sections (Scheduling, Memory), which is the natural home. If maintainers want these settable as global/user defaults too, I'm happy to add a global-defaults counterpart in a follow-up — just wanted to keep this PR focused and non-duplicative.
Testing
Settingstype (buildTimeoutMs?: numberatpackages/core/src/types.ts;insightExtractionEnabled?/insightExtractionSchedule?likewise), so the additions are type-safe.Summary by CodeRabbit