plandex-ai/plandex · error
Error updating default settings
Error message
Error updating default settings
What it means
UpdateDefaultSettingsHandler runs its work inside db.WithTx: it locks/reads current defaults (GetOrgDefaultSettingsForUpdate), deep-copies them, applies the model pack change, and stores them. Any error returned by the transaction closure (get-for-update failure, DeepCopy failure, unknown model pack name, store failure, or the tx itself failing to commit) is surfaced as 500 'Error updating default settings'.
Source
Thrown at app/server/handlers/settings.go:322
// log.Println("Original settings:")
// spew.Dump(originalSettings)
// log.Println("req.Settings:")
// spew.Dump(req.Settings)
err = db.StoreOrgDefaultSettings(auth.OrgId, settings, tx)
if err != nil {
log.Println("Error storing default settings: ", err)
return fmt.Errorf("error storing default settings: %v", err)
}
return nil
})
if err != nil {
log.Println("Error updating default settings: ", err)
http.Error(w, "Error updating default settings", http.StatusInternalServerError)
return
}
commitMsg := getUpdateCommitMsg(settings, originalSettings, true)
res := shared.UpdateSettingsResponse{
Msg: commitMsg,
}
bytes, err := json.Marshal(res)
if err != nil {
log.Println("Error marshalling response: ", err)
http.Error(w, "Error marshalling response", http.StatusInternalServerError)
return
}
w.Write(bytes)
View on GitHub (pinned to e2d772072e)
Solutions
- Read the 'Error updating default settings:' line in server logs for the wrapped cause (it prefixes 'error getting/storing/copying settings')
- Verify the modelPackName matches an existing model pack exactly
- Check DB health, lock contention, and that migrations are current
- Retry the update if it failed on a transient deadlock or serialization error
- If concurrent edits are common, serialize updates per org on the client side
Defensive patterns
Strategy: retry
Validate before calling
// client-side pre-check
if (!hasModelPack(req)) throw new Error('modelPackName or modelPack required');
const knownPacks = await api.listModelPacks();
if (req.modelPackName && !knownPacks.includes(req.modelPackName)) {
throw new Error(`Unknown model pack: ${req.modelPackName}`);
} Try / catch
try {
await api.updateDefaultSettings(req);
} catch (e) {
if (isTransient(e)) await backoffRetry(req, 3);
else throw e;
} Prevention
- Verify the model pack name exists before sending
- Retry on transient DB errors (deadlock, serialization) with backoff
- Avoid concurrent settings updates from multiple admins on the same org
- Keep migrations current so the settings tables match the code
When it happens
Trigger: Tx cannot read the org default row for update (missing row, lock timeout, deadlocks), DeepCopy fails, req.ModelPackName doesn't match any known model pack, StoreOrgDefaultSettings hits a constraint/DB error, or commit fails due to serialization/conflict.
Common situations: Concurrent settings updates from two admins causing lock waits/deadlocks; typo'd model pack name that SetModelPackByName can't resolve; migration lag so the settings row or columns don't exist; DB connection drop mid-transaction.
Related errors
- Error creating branch:
- Error inviting user:
- Failed to import custom models/providers/model packs:
- Error getting default settings
- Error deleting org user: {err.Error()}
AI-assisted analysis of plandex-ai/plandex@e2d772072e (2026-09-05).
Data as JSON: /api/errors/ffb36ddb3064a001.
Report an issue: GitHub.