Reporting problems

Build a bug report you read in full before sharing: what failed, the anonymised command journal, the redacted log, and how developers replay it.

Oxys DB Studio has no telemetry and sends nothing by itself. When something goes wrong, it builds a report on your computer, shows you every line of it, and lets you choose what happens next.

Build a report

There are three ways in:

  • Choose Help › Report a Problem… at any time. The report is about the last command that failed, if any.
  • Click Report this problem on an error dialog. The report is about that error. An internal error (a bug in the application) opens this dialog by itself.
  • After the application closed unexpectedly, the next start asks “Oxys DB Studio closed unexpectedly. Review and report?”. Review and Report… builds a report about that crash; Not Now does not. Either answer marks the crash as seen.

The Report a Problem dialog shows the exact text, laid out like the project’s bug template: summary, steps to reproduce and expected behaviour (for you to fill in), what failed, the environment, the command journal, the end of the log and your non-default settings. It also shows a fingerprint (the same problem gives the same one, which helps find duplicates) and a suggested label.

What is in it, and what is not

PartWhat you see
What failedThe command, the kind of error and its message, redacted
EnvironmentThe version, operating system and graphics adapter; for each open connection, the server version, topology (standalone, replica set, sharded cluster) and flavour. Never a host name.
Command journalThe last 200 commands (Edit › Preferences › General › Commands kept for problem reports, 0 turns it off), with their duration and result
Application logThe last 200 lines of log.txt
SettingsThe preferences you changed, without any password, passphrase, token or key

Names become tokens: your first connection is conn#1, a database db#1, a collection coll#1, and the same name always gives the same token, so the journal still reads as a story. Documents, filters, pipelines and scripts become their type and size, never their content. Connection strings, hosts, user names, passwords and file paths become <uri>, <host>, <user>, <secret> and <path> (a path keeps its file name). Read the text anyway: it is yours to edit before you post it.

Share it

  • Open GitLab Issue opens your browser on a new issue with the report as its text. A long report does not fit in a link: the issue then holds a summary and asks you to attach the .zip.
  • Copy to Clipboard copies the text.
  • Save .zip… saves report.md (the same text), journal.json (the same journal, for replay) and the screenshot, if you added one.
  • Save Logs Folder… writes the raw files instead (the logs with credentials masked, system information, your connections without passwords) to a folder on your computer and shows it, for you to attach what you choose.
  • Add Screenshot captures this window, without the dialog. It is only ever taken when you click, and only goes into the .zip.

Nothing is sent until you post the issue in your browser. For a security problem, do not open a public issue: see Security.

For developers: replay a report

oxysdb-cli replay report.zip --connection "Test server" --dry-run lists what the report’s journal would run; without --dry-run it runs it. Each db#N becomes a scratch database oxys_replay_db_N and each coll#N a collection coll_N (--prefix changes the prefix). It only runs database commands, refuses a connection marked production (red), and skips destructive commands (drop, delete, clear, rename, import) unless you add --allow-destructive.

For agents and scripts

app.report-problem returns the report text, the fingerprint, the label and the issue link without opening anything; app.report-problem-save writes the .zip. app.crash-report lists the crash reports waiting for review, and app.dismiss-crash-report marks them as seen. For the team server and the task runner, see oxysdb-server diagnose and oxysdb-runner diagnose in the deployment guide.