When data goes wrong

Esta página aún no está disponible en español. Se muestra la versión en inglés.

Loads fail, columns disappear upstream, and scheduled runs break at 3 a.m. This page explains what Querri does in each case so a bad load never quietly changes a number someone reports, and how you find out.

Who can see this: anyone in your organization. Each notice goes only to the people it’s about, listed in each section below.

The short version

What went wrong	What Querri does	Who’s told
Some rows of a CSV file can’t be read	Loads the rest, sets the unreadable rows aside and counts them	A Rows short of file note in the Data Audit
A sync removes or retypes a source’s columns	Records the change and lists what reads the source	The people who own the source and what’s built on it
A view fails to rebuild	Keeps the view’s last good data	The view’s owner and the owners of what’s built on it
A scheduled run hits a failed step	Repairs it with AI, or stops and keeps the last good results, as the project owner chose	The project owner
A connector schedule fails three times in a row	Turns the schedule off	Whoever created the schedule

Notices about failures and column changes arrive in the Inbox, by email, and to your organization’s outbound webhook if it subscribes to pipeline.failure.

See which rows were set aside

When Querri loads a CSV file, it tries strict readings first. If some rows still won’t parse, for example a row with too many columns or a date that isn’t a date, Querri loads the rows it can and keeps the others aside rather than dropping them without a word.

For each row kept aside, Querri records its line number in the file, the column, the reason, and the raw text of the line. It also counts the unreadable rows by reason on every load, so the total is always exact.

The table then gets a Rows short of file note in the Data Audit and in the table’s Data quality section in the Library. It’s marked Material, because every count, sum and average over the table is missing those rows. The note says how many rows couldn’t be read and why, for example “3 rows could not be read: 2 wrong number of columns, 1 invalid date”, and under it:

Unreadable rows kept aside: 3 · Download them

Download them saves the rows as a CSV file with each row’s line number, column, error, reason and raw text. Fix them in the original file and upload it again with Replace file….

Some details worth knowing:

Who can download them: your role needs the Download tables permission, which every role has unless an admin turns it off. You also need access to the whole table. Because the kept-aside rows are raw lines of the file, no row filter can apply to them, so someone whose view of the table is row-filtered by an access policy can’t download them.
How many are kept: up to 10,000 rows per load. The count on the note covers every unreadable row, even past that.
Each load replaces the last. The kept-aside rows always match the table’s latest finished load. A load that fails part-way leaves the previous load’s rows and counts as they were.
When the count itself fails, the note says the table’s rows were not checked against the file, and is marked Suspected. It doesn’t claim every row landed.

There’s no Inbox card or email for unreadable rows today. Check the Data Audit after a large upload.

See File Uploads for the upload side.

Get told when a source’s columns change

Every sync compares the columns a source had before with the ones it has now. That includes connector syncs, scheduled or by hand, and an upload’s Replace file….

A breaking change is a column that was removed, or whose type changed in a way that can break what reads it, such as a number column that now holds text. Querri files a notice.
An additive change, such as new columns, or a whole-number column that now holds decimals, is recorded but sends no notice, because nothing that read the old columns stops working.

A breaking change files a Schema change card in the Inbox titled “Columns changed in “Source name””, and sends the same notice by email and webhook. It says:

What changed: each removed column, each column whose type changed (old type → new type), and any added columns. When a removed and an added column have the same type, it says the column “may have been renamed”, and labels that a guess.
May be affected: the views, KPIs, monitors, projects and dashboards that read the source. When a view’s SQL mentions a removed column by name, the notice says so. That’s a text match, not traced lineage, so check the view before relying on it.

Who’s told: the source’s owner, the owner of its connector (or whoever ran the sync), and the owners of the views and projects built on it. Each person sees only the affected items they can open. The rest are counted, as in “2 other items you don’t have access to”, never named. Someone who can’t see the source itself isn’t told, unless they own it or its connector.

How often: the same change to the same source is announced at most once every 7 days, so a column that comes and goes between syncs is one notice, not one per sync. A different change is news and gets its own notice.

Querri doesn’t compare columns on a source’s first sync, when a sync returns no rows, or when a workbook’s list of sheets changed. On an incremental sync, which only brings in changed records, it reports new columns only, because a partial batch can’t show that a column is gone.

Choose what happens when a run fails

When a step fails, Querri can ask AI to rewrite the step’s code so the run can finish. That’s usually what you want. For a project whose numbers feed a board pack or a close, you may prefer that nothing rewrites a step while nobody is watching.

Each project has a When a step fails setting with two choices:

Choice	What it does
Repair with AI (the default)	“AI may rewrite a failed step’s code so the run can finish.”
Stop and keep previous results	”No AI code rewrites. A failed step keeps its previous code and results, and you get an inbox notice.”

To change it, open the project, click the arrow next to its title, choose Project Settings, and pick one under When a step fails. It saves as soon as you pick, shows Saved, and applies from the next run.

Only the project owner can change it. Anyone else sees “Only the project owner can change this.”

Which runs it applies to

The setting applies to runs nobody is watching: scheduled runs, runs through the API, and runs Querri starts because a source’s data changed. A run you start yourself always repairs failed steps, because you see the failure as it happens.

What Stop does

On a run with Stop and keep previous results:

A failed step keeps the code and the results it had when the run started. No AI rewrites its code.
If the failure looks temporary, such as a dropped connection or a warehouse that was busy, Querri tries the step once more with the same code.
Steps that depend on the failed step don’t run.
The step shows its previous results, marked “This run failed. Showing the results from the last successful run.”
The owner gets a card in the Inbox, ““Project name” stopped on a failed step”, naming the steps that failed. Retry runs them again, and Open project takes you there. The card goes away by itself once a later run completes those steps.

Steps that write commentary rather than code, such as summaries and research, still use AI on a stopped run.

When AI repairs a step

With Repair with AI, the project owner is still told when a step was rewritten on a run they weren’t watching, or on a run someone else started. The Inbox card reads “AI repaired a step in “Project name”” and names the steps. The previous code is in each step’s version history.

A failed view rebuild keeps the last good data

A view is rebuilt into a new copy. Only once the new copy is completely written does it replace the old one. If the rebuild fails part-way, the new copy is thrown away and the view keeps serving its last good data, exactly as it was. A failed rebuild never leaves a view half-filled.

Querri then files a View rebuild card, “The view “View name” failed to rebuild”, to the view’s owner and the owners of the KPIs and projects built on it. It says what went wrong in plain words, when the view last succeeded, and what’s still showing old data, such as “3 KPIs and the Board Pack dashboard are showing data as of Oct 22.” Retry rebuilds the view.

A view that fails on its very first build sends no notice: nothing depends on it yet.

Connector schedules that keep failing

When a connector’s scheduled sync fails three times in a row, Querri turns the schedule off so it doesn’t keep failing. Whoever created the schedule gets a Connector schedule card, “The scheduled sync for “Connector name” was turned off”, listing the tables that are now showing old data. Retry syncs the connector once, and Open goes to the connector. The schedule stays off until someone switches it back on. See Sync scheduling.

How failure notices behave

The view, schedule and project notices above follow the same rules:

One notice per failure. A view that fails every hour sends one notice, not one an hour. The next failure after it has succeeded again counts as a new one.
One reminder, for real failures only. A failed view rebuild, a connector schedule that was turned off, and a project run that stopped get one reminder if they’re still failing a day later. The reminder goes by email with “Still failing:” in the subject, and a view or schedule card in the Inbox is marked Still failing too. There’s no second reminder. An “AI repaired a step” notice gets no reminder, because the step works again.
Cards clear themselves. When the view rebuilds, the steps complete or the schedule is switched back on, the card is taken down. Dismiss removes a card yourself.
Each card shows in the workspace the view, connector or project belongs to.

Schema change notices never send a reminder. They follow the 7-day rule instead.

Send notices to your own systems

Admins can send the same notices to an endpoint they run, such as an incident tool or a chat channel, with the pipeline.failure webhook event. See Outbound webhooks for the payload.