feat(dashboard): auto-save config with 500ms debounce

[BillChirico]

Summary

Implements auto-save for the config dashboard. No more manual Save button.

Changes

• Auto-save — config changes are saved automatically 500ms after the last edit (debounced). Zero changes → zero network calls.
• Status indicator — replaces the Save button with a compact inline status:
  • (idle: nothing shown)
  • Saving... with spinner while in flight
  • ✓ Saved on success
  • ⚠ Save failed + Retry on error
• Initial load guard — isLoadingConfigRef prevents the config load from triggering a spurious auto-save
• Ctrl+S — still works; clears the debounce timer and saves immediately
• Validation errors — auto-save is suppressed while there are validation errors; a destructive banner replaces the old yellow banner
• Error recovery — Retry button re-fires saveChanges inline; partial failures still merge succeeded sections

Tests

4 new tests in config-editor-autosave.test.tsx:

• No PATCH on initial config load
• Validation banner shown + no PATCH when system prompt is too long
• Saving... spinner while PATCH is in-flight
• Save failed + Retry button on PATCH 500

Test Results

Test Files  21 passed (21)
     Tests  145 passed (145)

Closes #189

[coderabbitai]

Warning

Rate limit exceeded

@BillChirico has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 12 minutes and 28 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 2791afb and 61d6f1d.

📒 Files selected for processing (2)

• web/src/components/dashboard/config-editor.tsx
• web/tests/components/dashboard/config-editor-autosave.test.tsx

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/issue-189

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

Implements debounced auto-save for the dashboard config editor, replacing the manual “Save Changes” button with an inline save-status indicator and adding tests to validate the behavior.

Changes:

• Adds 500ms debounced auto-save (plus Ctrl/Cmd+S immediate save) and suppresses auto-save during validation errors / initial load.
• Introduces an inline auto-save status indicator (Saving/Saved/Error + Retry).
• Adds a new test suite covering initial-load no-PATCH, validation suppression, saving UI, and error UI.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 9 comments.

File	Description
web/src/components/dashboard/config-editor.tsx	Adds auto-save debounce logic, status indicator UI, and wiring into existing save/load flows.
web/tests/components/dashboard/config-editor-autosave.test.tsx	Adds integration-style tests for auto-save behavior and status UI states.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[greptile-apps]

Greptile Summary

Replaces manual save button with auto-save that debounces changes at 500ms. Config changes trigger automatic persistence with inline status indicators (Saving.../Saved/Save failed + Retry). Includes initial load guard to prevent spurious saves, validation error blocking, and Ctrl+S for immediate save. Tests verify no PATCH on mount, validation blocking, and all status states.

Key improvements:

• Auto-save eliminates need for manual save button, improving UX
• Debouncing prevents excessive network calls
• Status indicators provide clear feedback
• Comprehensive test coverage for core scenarios

Issues found:

• Ref-based change detection has a timing race: if server responds before React effect runs, pending user edits can be overwritten (low probability but possible on fast networks)
• Discard button doesn't clear save status indicator

Confidence Score: 3/5

• This PR improves UX but has a low-probability race condition that could lose user edits
• Score reflects solid implementation with good test coverage, but the ref timing issue in the race condition fix (line 248-251, 389) is a real logic bug that could lose user data under fast network conditions. The mitigation attempt doesn't fully resolve the original race condition comment. The missing status reset on discard is minor. Auto-save logic, debouncing, and validation blocking are correct.
• Pay close attention to web/src/components/dashboard/config-editor.tsx lines 248-251 and 389 for the ref timing race condition

Important Files Changed

Filename	Overview
web/src/components/dashboard/config-editor.tsx	Implements auto-save with 500ms debounce, status indicator, and race condition mitigation. Has a timing issue in ref-based change detection that could lose edits on fast servers, plus missing status reset on discard.
web/tests/components/dashboard/config-editor-autosave.test.tsx	Comprehensive test coverage for auto-save: validates no spurious saves on load, validation error blocking, status UI states, and error retry.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    Start([User edits config]) --> Check{Check guards}
    Check -->|isLoading=true| Block[Block auto-save]
    Check -->|No changes| Block
    Check -->|Validation errors| Block
    Check -->|Already saving| Block
    Check -->|All guards pass| ClearTimer[Clear existing debounce timer]
    ClearTimer --> SetTimer[Set 500ms debounce timer]
    SetTimer --> Wait[Wait 500ms]
    Wait --> Save[Execute saveChanges]
    Save --> SetSaving[Set status='saving']
    SetSaving --> Snapshot[Capture draftSnapshot]
    Snapshot --> Patch[Send PATCH requests]
    Patch --> Success{All succeeded?}
    Success -->|Yes| CheckChanges{draftConfigRef == snapshot?}
    CheckChanges -->|Equal - no edits during save| Reload[fetchConfig from server]
    CheckChanges -->|Not equal - user edited| UpdateSaved[Update savedConfig locally]
    UpdateSaved --> StatusSaved[Set status='saved']
    Reload --> StatusSaved
    StatusSaved --> TriggerNext{hasChanges?}
    TriggerNext -->|Yes| Start
    TriggerNext -->|No| Idle[Set status='idle']
    Success -->|Partial/failed| Error[Set status='error']
    Error --> ShowRetry[Show Retry button]
    Block --> End([End])
    Idle --> End
    ShowRetry --> End

Loading

_{Last reviewed commit: 61d6f1d}

[greptile-apps]

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When saveStatus is saved, making a new edit doesn’t clear it, so the UI can still display “Saved” during the 500ms debounce window even though there are unsaved changes. Consider resetting saveStatus back to idle (or a dedicated “pending changes” state) as soon as hasChanges becomes true, so the indicator doesn’t misrepresent the current persistence state.

[Copilot]

isLoadingConfigRef is cleared via setTimeout(..., 0) without checking that the completing request is still the latest one. If the guild changes quickly (or multiple fetchConfig calls overlap), an earlier request can flip the ref to false while a newer load is still in progress, allowing auto-save to run during load. Consider tracking a request id / comparing abortRef.current === controller inside the timeout (and in the error/abort paths) before clearing the flag.

Suggested change

	// Use a macrotask so the state setter for draftConfig fires before we clear the flag
	setTimeout(() => {
	isLoadingConfigRef.current = false;
	}, 0);
	setDmStepsRaw((data.welcome?.dmSequence?.steps ?? []).join('\n'));
	setProtectRoleIdsRaw((data.moderation?.protectRoles?.roleIds ?? []).join(', '));
	} catch (err) {
	if ((err as Error).name === 'AbortError') return;
	isLoadingConfigRef.current = false;
	// Use a macrotask so the state setter for draftConfig fires before we clear the flag.
	// Only clear the loading flag if this request is still the active one.
	setTimeout(() => {
	if (abortRef.current === controller) {
	isLoadingConfigRef.current = false;
	}
	}, 0);
	setDmStepsRaw((data.welcome?.dmSequence?.steps ?? []).join('\n'));
	setProtectRoleIdsRaw((data.moderation?.protectRoles?.roleIds ?? []).join(', '));
	} catch (err) {
	if ((err as Error).name === 'AbortError') return;
	// Only clear the loading flag if this request is still the active one.
	if (abortRef.current === controller) {
	isLoadingConfigRef.current = false;
	}

[Copilot]

On full success, this sets status to saved and then calls fetchConfig, which toggles the global loading state and re-fetches the entire config. With auto-save, this can introduce frequent extra GETs and briefly replace the editor with the loading screen after each save. Consider avoiding the full reload (update savedConfig from draftSnapshot / server response) or adding a background-refresh mode that doesn’t flip loading/hide the editor.

[Copilot]

AutoSaveStatus is rendered solely from saveStatus, so it can remain visible (e.g., Save failed or Saved) even after the user discards changes and hasChanges becomes false. Consider resetting saveStatus to idle when discarding/when hasChanges becomes false, and wrap onRetry to also clear any pending debounce timer (similar to the Ctrl+S handler) to avoid double-saves.

Suggested change

	<AutoSaveStatus status={saveStatus} onRetry={saveChanges} />
	<AutoSaveStatus status={hasChanges ? saveStatus : 'idle'} onRetry={saveChanges} />

[Copilot]

AutoSaveStatus uses <output> for the status text, but it isn’t marked as a live region, and the error variant nests an interactive <button> inside <output>. For better screen reader behavior, consider using role="status"/aria-live="polite" on a non-output wrapper (e.g., a <div>/<span>) and keep the Retry button as a sibling element.

[Copilot]

This test hard-codes the system prompt max length as 20000, but the app constant SYSTEM_PROMPT_MAX_LENGTH is currently 4000 (web/src/types/config.ts). Import and use the shared constant here (and build the over-limit string based on it) to avoid drift and to keep the test input smaller/faster.

[greptile-apps]

ref update timing issue: draftConfigRef.current is updated asynchronously in this effect after renders, but saveChanges (line 389) checks it synchronously after PATCH completes. If the server responds before this effect runs (e.g., user types → render scheduled → PATCH completes → ref still has old value), the check incorrectly concludes no changes occurred, calls fetchConfig, and overwrites the user's pending edits.

Consider updating the ref synchronously when setDraftConfig is called, or use a different approach like comparing against the latest state in a ref callback.

Prompt To Fix With AI

This is a comment left during a code review.
Path: web/src/components/dashboard/config-editor.tsx
Line: 248-251

Comment:
ref update timing issue: `draftConfigRef.current` is updated asynchronously in this effect after renders, but `saveChanges` (line 389) checks it synchronously after PATCH completes. If the server responds before this effect runs (e.g., user types → render scheduled → PATCH completes → ref still has old value), the check incorrectly concludes no changes occurred, calls `fetchConfig`, and overwrites the user's pending edits.

Consider updating the ref synchronously when `setDraftConfig` is called, or use a different approach like comparing against the latest state in a ref callback.

How can I resolve this? If you propose a fix, please make it concise.