Reliability and support.

Crash recovery#

While you work, Plasma writes a small snapshot of your session to disk: your open tabs and their SQL, the grid edits you have staged (with the original values they were staged against), and whether a transaction was open. It is saved atomically, so a crash in mid-write leaves the previous complete snapshot. After a crash, a force-quit or a power cut, the next launch brings the session back.

• A notice names what happened: Plasma closed unexpectedly, or The Plasma window crashed and was reloaded, and what came back (“Restored 4 tabs and 3 unsaved edits.”). It can offer Discard edits and Show crash log.
• Nothing is replayed. Restoring re-opens tabs and re-stages edits; it never runs a statement. Staged edits are not committed until you commit them.
• A transaction that was open is gone, and the notice says so: “Your open transaction was rolled back, so its changes are gone.”
• If a commit was in flight when Plasma stopped, those edits come back flagged as possibly already saved, with a reminder to check the data before committing. If something could not be saved (an edit, or a SQL tab too large), the notice counts it as lost.
• Snapshots belong to a connection. If the saved connection now points at another host or database, the edits are not applied there; the notice Saved work belongs to a different database lets you Open its SQL or Discard it. A snapshot whose connection no longer exists is offered as Unsaved work from an earlier session with Discard or Keep for later.

Separately, closing the window with unsaved work asks first, and starting a second copy of Plasma on the same profile just brings the first one forward.

Connection loss and reconnecting#

A laptop that sleeps, a Wi-Fi change or a VPN reconnect can leave Plasma holding sockets whose other end is gone. Plasma detects that a failure was a lost connection (as opposed to a SQL error, which never triggers a reconnect) and handles it in two layers.

1. 01

   A silent retry

   The first time a request comes back as a lost connection, Plasma rebuilds the session (including the SSH tunnel) and retries the request once. This is done for reads only. A write is never replayed: it reports that the connection dropped, and what you see is described below.

2. 02

   Automatic reconnect

   If that fails, the connection capsule reads Reconnecting to <name>… (attempt N). Plasma tries again after 2, 5, 10, 30 and 60 seconds, and again as soon as the network comes back. When it gives up the capsule reads Couldn’t reach <name> — click to reconnect, with the plain-language reason. Clicking the capsule reconnects at any time. Stop reconnecting in the connection menu ends the attempts.

• Settings → General has Connection lost: Retry automatically (on by default) and On launch: Reconnect to the last connection. A deliberate disconnect is remembered, so Plasma does not reconnect after it on the next launch. If the database is unreachable at launch, the same retry schedule applies.
• A tab whose statement was cut off by the drop says Connection dropped (a read; run it again) or Outcome unknown (a write, which Plasma does not repeat).

Support bundle#

When something goes wrong, a support bundle gives whoever is helping you the facts without your data. Create it from Help → Create Support Bundle…, the command palette (Create support bundle…), or Settings → Advanced → Create support bundle….

The dialog lists every file with its size and a one-line description, and shows each file’s exact text. You review all of it before anything is saved, then choose where to save a .zip. Nothing is uploaded; you decide who gets the file.

• It never holds query results, SQL you wrote or ran (history, snippets, saved queries, tabs, start-up SQL, SQL that an error quotes), row data, passwords, keys, tokens or connection-string secrets.
• Also hide host names and user names replaces them (and IP addresses and e-mail addresses) with placeholders such as host-1 and user-1, and the preview updates so you can see the result.

Logs#

The app log is logs/main.log inside Plasma’s user-data folder, capped at 5 MB per file. Renderer messages in a shipped build are not written to it, because they can carry query text. SQL and error text that does reach the log is redacted the same way as the query history. The user-data folder is normally ~/Library/Application Support/Plasma on macOS, %APPDATA%\Plasma on Windows and ~/.config/Plasma on Linux; if you set the PLASMA_USER_DATA environment variable, that folder is used instead, which is also how you run a second profile alongside the first.

Isolation#

Database drivers run in a separate worker process, not in the window. A driver that hangs or crashes does not freeze the interface; a long query can be cancelled because the worker listens for it, and the app restarts the worker if it exits unexpectedly, and pending requests are failed rather than left hanging.