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

  1. Read the 'Error updating default settings:' line in server logs for the wrapped cause (it prefixes 'error getting/storing/copying settings')
  2. Verify the modelPackName matches an existing model pack exactly
  3. Check DB health, lock contention, and that migrations are current
  4. Retry the update if it failed on a transient deadlock or serialization error
  5. 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

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


AI-assisted analysis of plandex-ai/plandex@e2d772072e (2026-09-05). Data as JSON: /api/errors/ffb36ddb3064a001. Report an issue: GitHub.