←
TRCKR-221
Created: 2025-12-09
•
Updated: 2025-12-16
Relationships
Loading...
Attachments
Loading...
Comments (2)
agent
·
2025-12-10
**Additional Fix for Production:**
After deploying the initial fix, discovered that existing production databases didn't have the settings table (added in TRCKR-197). This caused 'no such table: settings' errors.
**Root Cause:**
The _ensure_server_tables() migration function in server/database.py was only creating server-specific sync tables (sync_history, sync_snapshots) but not the settings table.
**Solution:**
Updated server/database.py line 52-70 to ensure settings table is created when the server starts:
- Added SETTINGS_TABLE import
- Added conn.execute(SETTINGS_TABLE) before sync table migrations
**Verification:**
- Deployed to production (commit 522f75c)
- Tested API endpoints successfully:
- PUT /api/settings/test.production returns 200 OK
- GET /api/settings/test.production returns saved value
- Settings modal should now work correctly on production server
The fix automatically migrates existing databases without requiring manual intervention.
agent
·
2025-12-10
Fixed the settings modal save functionality.
**Root Cause:**
The issue was in server/database.py line 84-96. The get_db() function was using @contextmanager decorator to create a synchronous generator context manager, but FastAPI's dependency injection system expects either a simple callable or an async context manager. When FastAPI tried to use this in an async context, it caused an AttributeError: '_GeneratorContextManager' object has no attribute 'throw'.
**Changes Made:**
1. server/database.py:
- Removed @contextmanager decorator from get_db() (line 84)
- Converted get_db() to a simple function that returns the shared LocalStore instance (lines 84-90)
- Removed unused imports (contextmanager, Generator)
2. tests/test_settings_web.py (new file):
- Added comprehensive tests for settings API endpoints
- test_get_settings_api: Verifies GET /api/settings works
- test_update_setting_api: Verifies PUT /api/settings/{key} works
- test_update_multiple_settings: Simulates the saveSettings() JavaScript function behavior
- test_settings_modal_html: Verifies the settings modal HTML renders correctly
**Testing:**
- All new tests pass (4/4)
- Verified API works with curl:
- PUT /api/settings/issue.default.assignee returns 200 OK with updated value
- GET /api/settings/issue.default.assignee returns saved value
- The settings modal JavaScript (saveSettings() function) now works correctly because the API endpoints are functional
**Files Modified:**
- /private/tmp/trckr-TRCKR-221/server/database.py (lines 7-8, 84-90)
- /private/tmp/trckr-TRCKR-221/tests/test_settings_web.py (new file, 106 lines)