The database helper is off for this run (what the amber strip means)

What it is

The helper this strip is about

Omniscio keeps everything it remembers (sessions, messages, settings) in one database file on your computer, and that file can be many gigabytes. Reading and writing it takes time, and much more of it when the disk is busy or a lookup has to pull a large part of the file back in from the disk, for example right after a restart.

The app used to do all of that on the same part of the app that paints the window, so a big enough lookup could freeze the window for as long as it took. The database helper moves that work into separate background processes, so the window keeps moving while the database is busy. It is a small group of processes, one for each lane of work:

• one for the lookups you are actively waiting on, such as opening a session or scrolling through it;
• one for background work, such as pollers, snapshots and housekeeping;
• one, read-only, for large scans.

Each lane has its own process and its own connection to the same database file, so a slow background job cannot make a session you are opening wait behind it.

The helper is on by default on computers with at least 13 GB of memory. Smaller computers use the older mode automatically, because each helper process holds its own large view of the database. You can switch the helper off or on yourself, and the switch applies immediately.

The single-connection mode

Without the helper, Omniscio uses one connection to the database, on the part of the app that draws the window. That is how it worked before the helper existed. It gives the same answers; it is just more likely to freeze for a moment when the disk is slow or a big lookup runs.

When the strip appears

The strip appears when Omniscio itself decides, for this run, that the helper cannot be relied on. There are exactly two ways to get there:

1. The helper could not start. At launch, if the helper does not come up, Omniscio tries again five more times, 30 seconds apart. The strip appears only when every one of those tries has failed.
2. The helper keeps crashing. If a helper process dies five times in a row without finishing a single job in between (or five times in a row without ever becoming ready), Omniscio stops using the helper for the rest of the run.

Omniscio makes this decision at most once per run, and it does not take it back until you restart.

The strip does not appear because the helper is merely slow, because a long queue built up, or because a stuck job was replaced. A helper that crashes right after doing work is restarted after a growing pause (at once the first time, then 1, 2 and 4 seconds, and so on, never more than 60 seconds) instead of being given up on. The strip also does not appear when you have switched the helper off yourself or when your computer is below the 13 GB floor, because there the single-connection mode is a deliberate choice, not a failure. Nor does it appear when one of the optional extra read-only helpers drops out: that costs a little spare capacity, and the main helpers keep serving.

Where to find it

At the very top of the Omniscio desktop window. Phones and browsers do not show it.

It is one of the thin health strips at the top of the window, alongside the offline notice and the Safe Mode banner (see App shell and health banners). Unlike the "app may be frozen" strip, which floats over the window, this one makes room for itself, so nothing is covered. It has no close button and stays until you restart Omniscio. Screen readers announce it politely when it appears.

Its button, Open Performance settings, takes you to Settings, then Performance, and highlights the switch named Run the database on a background thread, which turns the helper on or off (see Performance settings).

How it behaves

What you see

• A bold line, The database helper is off for this run, followed by "Omniscio is using its single-connection mode until it restarts. You may notice short freezes; nothing is lost." and the Open Performance settings button.
• It appears on its own the moment Omniscio makes the decision. While the decision stands, Omniscio repeats the notice every 15 seconds, so a window you reload or open later shows it within about 15 seconds.
• It does not go away by itself, and it makes no sound and adds nothing to your inbox.

What to do

• Nothing is urgent. Omniscio keeps working, and nothing you saved is lost.
• When it suits you, restart Omniscio. A new run tries the helper from scratch, and the strip is gone if the helper comes up.
• Switching the setting off and on again does not bring the helper back during this run: the decision stands until you restart. The switch is still the place to turn the helper off on purpose. A helper you switched off yourself shows no strip on the next start, because nothing failed.
• If the strip keeps coming back after restarts, treat it like any slowness problem. Computer feels slow? lists the free fixes in order, and the Performance Monitor shows how the computer is doing. The strip does not say why the helper failed.

What it is not

• Not an inbox card. An inbox card is itself a database write, and the database helper is exactly what is off, so Omniscio tells you with a strip instead. An earlier version raised an inbox card for this (its internal name was db-worker-reverted). That card is no longer raised, and an old one left over from an earlier run clears itself the next time Omniscio starts the helper successfully.
• Not a sign that data was lost. The single-connection mode reads and writes the same database file.
• Not a slowness warning. It never appears just because Omniscio is slow.
• Not retried automatically. After a failed launch or a crash loop, Omniscio does not try to bring the helper back during the same run. A failed launch therefore keeps the whole run in the older mode. One slow retry for that case is a possible future change; today there is none.

Lookups in progress

When the helper stops, any lookup that was waiting on it is told "could not ask", never "there is nothing there", so a half-finished lookup cannot look like an empty list. New lookups then use the single-connection mode.

How we know the helper really works

Every promise the helper makes is about things no small, isolated test can reach: a real separate process, a real second connection to the same database file, and a live switch-over in the middle of a run. The failures that matter look fine from the outside:

• The switch flips and nothing starts. Every lookup quietly stays on the part of the app that draws the window, the app looks and behaves the same, and the whole feature is inert.
• The helper starts, but the app reads from a different connection than it writes to, so a rename is saved and the next read still shows the old name.
• Turning it off leaves the helper running, or drops the app back to the older mode having lost something the helper wrote.
• The hard off switch stops winning, so someone who disabled the helper on a computer it hurts gets it anyway.

So an end-to-end test launches the real app and walks through it. It switches the helper off and checks that no helper process exists, renames a session and reads the list back, switches the helper on and checks that one helper process per lane appears, renames the session again and reads it back through the helper, then switches the helper off and checks that the processes are gone and the last name is still there. A second test sets the hard off switch, turns on every setting that could start the helper, waits 20 seconds, and checks that no helper appears while the app still reads and writes.

That test does not claim the 13 GB memory floor, the routing between the three lanes, warm-up timing or the archive health check; other tests cover those. The decision that produces the strip has its own timed proof. It uses a stand-in database (never a copy of your real one) and real helper threads that are killed one after another until the crash-loop decision falls. It first shows that it can see a freeze, by running a deliberately slow lookup in the single-connection mode. Then it checks that, once the decision has fallen, every lookup that was waiting on the helper is refused instead of being quietly re-run on the part of the app that draws the window, and that this part stays free: no database statement runs there and it never stalls for more than half the length of the slow lookup.

Related

• App shell and health banners: the other strips at the top of the window (offline, reconnecting, the app may be frozen, Safe Mode) and how each clears.
• Performance settings: the switch named Run the database on a background thread, and the other performance switches.
• Performance Monitor: a read-only readout of how the computer and the app are doing right now.
• Computer feels slow? A step-by-step fix-it guide: the free fixes in order, new hardware last.