Skip to main content
Start with the affected page in General Validation. Note the error code and request ID when the app shows them, and the Run ID for anything about a Run. General Validation records configuration, status, and Result summaries. Spark execution, exact values, and mismatch evidence stay in your Fabric tenant, so some symptoms are resolved in Fabric rather than in the app.

What you see and what to do

Fabric monitoring

Your browser submits each Run as a job of the Spark Job Definition named General Validation executor in your dedicated workspace. Click View in Fabric on Environment or on a Run to open that workspace. Fabric’s monitoring for the workspace lists each job with its status and Spark logs and diagnostics; those stay in Fabric, and General Validation records only a fixed reason for a failed submission or job, never Fabric’s message. A Run whose Tests fail also shows as failed in Fabric monitoring. Open the Run in General Validation to see whether a Test failed or the execution itself had a problem. If the Run’s page says “No results were saved for this Run.”, open the job in Fabric to see why. Each Run writes its summary, a details file with exact values, and Parquet mismatch evidence to the GeneralValidationResults Lakehouse under Files/GeneralValidation/results, in a folder named with the Run ID. The Run’s page shows the first eight characters of the Run ID; the full ID is in the page address. Each Run also keeps the exact instructions it executed, which you can review in the Run’s folder and in Fabric’s Spark monitoring. Previews in the app show at most 100 mismatched rows; query the Parquet files with a notebook or SQL endpoint in Fabric for the complete evidence. You own these files and control their retention. General Validation never deletes them; Remove on Environment deletes the whole dedicated workspace, including this Lakehouse.

Request IDs and support

When a General Validation API call fails, the app shows the error code and a request ID with the message. Send these to support@generalvalidation.com:
  • the error code and the request ID, or the Run ID for anything about a Run;
  • the time it happened, in UTC;
  • the page you were on and what you clicked.
Failures during setup, browsing workspaces and Tables, Run submission, status checks, and evidence previews have no request ID, because those calls go from your browser straight to Microsoft. For those, send the Run ID where there is one and what Fabric monitoring shows for the job. Keep rows, exact values, credentials, tokens, and evidence files in your tenant. Do not attach them, and review screenshots so they do not include them. Support does not need them: General Validation’s operational logs hold request IDs, operation states, error codes, and a fixed set of diagnostic metadata, and never tokens, credentials, request or response bodies, filter values, exact values, or rows. Those logs are retained for 30 days. The Error codes reference lists every code the app can show with its next step.

Browser diagnostics

General Validation writes fixed-field diagnostic records to your browser’s developer console for sign-in, API calls, and page rendering. Each record holds the action, its outcome and status, the error code, and the request ID. Records never contain tokens, headers, request or response bodies, query strings, account or directory identifiers, page text, full addresses, or error messages and stack traces. They stay in your browser and are not sent to General Validation. Review a record before sharing it; after review it is safe to include in a support message. Requests your browser makes directly to Fabric and OneLake, for Environment setup, browsing, Run submission, status checks, summary import, and evidence previews, produce no console record and no General Validation log. Use Fabric monitoring for those.