#11 Fix Saving Settings Issue and Prevent Duplicate Rows

[Copilot]

Fixed settings not persisting after save and eliminated duplicate settings rows in the database caused by race conditions.

Problems Addressed

1. Settings Not Persisting: Settings changes were not saved - reloading the page would reset values to their previous state
2. Duplicate Rows: Multiple settings records were being created in the database due to race conditions

Root Causes

1. getSettings() was wrapped with React's cache(), which maintains a request-scoped cache that persists beyond Next.js's revalidatePath() invalidation
2. Client-side UI wasn't automatically refreshing after save
3. The find-then-create-or-update pattern had a race condition that could create duplicate settings rows when multiple requests were processed concurrently

Solution

Settings Persistence (commits 74e3b33, b16d523)

• Removed React cache() wrapper from getSettings() which was preventing fresh data fetches after revalidatePath() was called
• Added router.refresh() call in the settings form after successful save to trigger an immediate client-side refresh

Duplicate Row Prevention (commits 749992c, d8fde4d)

• Introduced fixed ID constant SETTINGS_ID = 'default' for singleton settings record
• Replaced find-then-create-or-update pattern with Prisma's upsert operation in both getSettings() and updateSettings()
• Extracted common settings data object to reduce duplication

The upsert operation atomically creates or updates the settings record in a single database transaction:

• where: { id: SETTINGS_ID } - looks for record with fixed ID 'default'
• update: settingsData - updates if found
• create: { id: SETTINGS_ID, ...settingsData } - creates with fixed ID if not found

This eliminates the race condition that caused duplicate rows and ensures there's only ever one settings record in the database.

Testing

• ✅ TypeScript compilation passes
• ✅ Build process completes successfully
• ✅ Code review: 0 issues found
• ✅ CodeQL security scan: 0 alerts found

Note: Any existing duplicate settings rows in the database will need to be manually deleted. Going forward, only one settings record with ID 'default' will exist.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Saving settings has no effect</issue_title>
<issue_description>Changing settings and saving them doesn't seem to do anything. Reloading the page resets them to their previous values and nothing on the site is properly updated</issue_description>

<agent_instructions>Issue number is #11</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes b-at-neu/senate-path#11

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
senate-path	Ready	Preview, Comment	Feb 16, 2026 1:49am

[b-at-neu]

@copilot the bug persists. To recreate, edit the settings and then click save. Then reload the page and the settings will go back to outdated values. Curiously, it seems if you do this twice in a row maybe the settings from the first time saving appear?

[Copilot]

@copilot the bug persists. To recreate, edit the settings and then click save. Then reload the page and the settings will go back to outdated values. Curiously, it seems if you do this twice in a row ...

I've identified and fixed the issue. The problem was that after saving settings, the client-side UI wasn't refreshing even though the database was updated and revalidatePath() was called.

The fix adds router.refresh() in the settings form after a successful save (commit b16d523). This triggers an immediate client-side refresh to fetch and display the updated settings.

The "settings from the first time saving appear on the second save" behavior you noticed was because revalidatePath() marks the path as stale, so the next navigation would fetch fresh data - but not the current page unless explicitly refreshed.

Now when you save settings, the page will automatically refresh and show the updated values immediately.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• checkpoint.prisma.io
  • Triggering command: /opt/hostedtoolcache/node/24.13.0/x64/bin/node /opt/hostedtoolcache/node/24.13.0/x64/bin/node /home/REDACTED/work/senate-path/senate-path/node_modules/prisma/build/child {"product":"prisma","version":"6.18.0","cli_install_type":"local","information":"","local_timestamp":"2026-02-14T20:01:30Z","project_hash":"7e6c9fe6","cli_path":"/home/REDACTED/work/senate-path/senate-path/node_modules/.bin/prisma","cli_path_hash":"8aa2e4f1 (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[b-at-neu]

@copilot why does my settings table have two rows in it? Use the built-in create or update from prisma instead of the weird pattern that is happening right now

[Copilot]

@copilot why does my settings table have two rows in it? Use the built-in create or update from prisma instead of the weird pattern that is happening right now

Fixed in commits 749992c and d8fde4d. The duplicate rows were caused by a race condition in the find-then-create-or-update pattern.

I've refactored both getSettings() and updateSettings() to use Prisma's upsert operation with a fixed ID ('default'). This atomically creates or updates the settings record in a single database transaction, preventing duplicates.

The upsert pattern ensures only one settings record will exist going forward. You may need to manually delete the extra row(s) from your database.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• checkpoint.prisma.io
  • Triggering command: /opt/hostedtoolcache/node/24.13.0/x64/bin/node /opt/hostedtoolcache/node/24.13.0/x64/bin/node /home/REDACTED/work/senate-path/senate-path/node_modules/prisma/build/child {"product":"prisma","version":"6.18.0","cli_install_type":"local","information":"","local_timestamp":"2026-02-16T01:46:00Z","project_hash":"7e6c9fe6","cli_path":"/home/REDACTED/work/senate-path/senate-path/node_modules/.bin/prisma","cli_path_hash":"8aa2e4f1 (dns block)
  • Triggering command: /opt/hostedtoolcache/node/24.13.0/x64/bin/node /opt/hostedtoolcache/node/24.13.0/x64/bin/node /home/REDACTED/work/senate-path/senate-path/node_modules/prisma/build/child {"product":"prisma","version":"6.18.0","cli_install_type":"local","information":"","local_timestamp":"2026-02-16T01:46:02Z","project_hash":"7e6c9fe6","cli_path":"/home/REDACTED/work/senate-path/senate-path/node_modules/.bin/prisma","cli_path_hash":"8aa2e4f1 (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)