Report a problem

Navigate: the Report a Problem action on an error message, on the error screen, on a run's page, or in the help drawer. Support is by email to [email protected].

When something goes wrong, the fastest way to get it fixed is to send us a Diagnostic Bundle with your email. It is one .json file that describes the problem without carrying your data, so we can diagnose it without asking you a round of follow-up questions.

---

When to use it

• A run ended in a state you did not expect, or failed and you cannot see why.
• An error message appeared in the application. Each one shows an error reference - include it; the bundle matches it to what the platform recorded.
• A run or a screen seems stuck, slow, or wrong.
• You suspect a false pass: a run reported clean and the data differs. Say so in the first line of your email. We treat it as the highest severity whatever the row count.

Who can create one

operator, tenant_admin and platform_admin. An analyst or auditor sees the error reference and is asked to pass it to an operator, who creates the bundle. See Access, roles and audit.

Every bundle that is created is recorded in the Audit Log: who created it, for which run or mapping, and whether names were included.

What the bundle contains

The preview in the application lists each section before you download. In plain words:

Section	What it carries
Header	The bundle format version, your Paridity version and build, your tenant's opaque id, the role of the person who created it, and the reference of the request that made it.
Error references	For each error reference you include: when it happened and what kind of action it was (time, action, entity type, category, severity). If your access is limited to some business domains, only records about the bundle's run or mapping are matched, and none when you name neither.
Run	The run's status, its phases with start and end times and durations, readiness outcomes, a schema-drift summary (counts only), lag-retry counts, whether a comparison window was found and how long it spanned, and the run narrative and triage with their wording replaced by tokens.
Mapping	The mapping's opaque id, the two engine types, the replication tool, the watermark strategy, the CDC mode, and the non-name configuration settings with per-field counts.
Anomalies	How many anomalies are open, by analyzer and severity. Counts only.
Workers	Each worker's id, queue, version, build and last heartbeat.
Health	Whether the database and the workflow engine answered.
Your browser	The page you were on (without any search text), your browser's user agent, and the time, status and code of recent errors the page showed.

The bundle's own redaction manifest says, section by section, what was kept and what was removed. You can read it in the file before you send it.

What it never contains

Under any setting, the bundle never contains:

• data values - no field values, key values, watermark or window values, and no field-level differences;
• hash totals or row hashes;
• credentials, secrets or connection references;
• SQL text or decrypt expressions;
• column names;
• raw logs;
• the name or email of the person who created it.

Free text that could quote a name or a value - error messages, reasons, the narrative's prose - is replaced as a whole by a token such as <OBJECT:3f9a1c2e>. Tokens are consistent within one bundle, so we can see that two sections refer to the same thing, and they are salted for that one export, so they cannot be turned back into the names.

Including mapping and table names

By default every mapping, table and tenant name is a token. Tick Include mapping and table names when it would help us to know which table is affected. That keeps exactly:

• the mapping name;
• the source and target table names (schema.table). For a file or object-store path only the scheme is kept (for example abfss://); the bucket, account and path stay a token;
• your tenant name.

Column names are never included, with or without this option. The choice is made for each bundle and is recorded in the Audit Log.

Sending it

1. Click Report a Problem, read the preview, choose whether to include names, and download the file.
2. Your email client opens a message to [email protected] with the error reference and the bundle's file name filled in.
3. Attach the downloaded file and send. Nothing is sent automatically - the bundle leaves your environment only as the attachment you send.

Paridity keeps a copy of the bundle for up to 24 hours in its own database, so a retried download returns the same file. It is not stored anywhere else and is never sent anywhere by the platform.

If you also have an evidence export for the run, you can attach it as well; see Evidence.