When a job fails#

When a run fails or completes with warnings, Reportworq keeps a per-run diagnostics archive so you can see exactly what happened. Read the log to see what went wrong, work through the common causes, and, when needed, escalate to support with the right logs. This page shows how to find the cause and escalate.

When to use it. Any time a run shows Failure or Warnings, or a job appears to succeed but produces no output. Start here before re-running blindly.

Open the diagnostics for a failed run#

1. Find the failed run in Activity (filter to Failures) or in the distribution job's Run History.
2. From Activity, select Details on the run. From Run History, open the failed run; a failed run shows a one-line error above its outputs, with Run again (if you can edit the job) and Show details. Select Show details to read the full message, the trace and what to try next; Copy puts them on your clipboard.
3. This opens the run, on its Details tab. The other tabs are Progress, which shows how the run went, step by step; Performance, which is present on every run (see Review a run's performance); Timeline; and Compare. The run's log, attachments, and trace are in the Advanced diagnostics section on the right side of Performance, beneath the Engines table. It starts collapsed; select it to open it.

Select Show details to open the Error details dialog. It holds the full message, the trace in its own scrolling box, and what to try next.

Read the log#

1. In Advanced diagnostics, under Logs, select the job log's name to open it, and read the entries top to bottom. Each has a line number, timestamp, elapsed time, and message. An error entry expands to show the exception message and stack trace.
2. The first 250 entries load; select Show Full Log to see the rest.
3. Attachments lists any files the run produced: select a name to open it. The HTTP trace (one row per request: select its address to see the request and response) is there too, which are present only if Trace logging was on for the run. To capture traces, re-run the job with Verbose and Trace logging enabled (see Run a job).
4. Every row ends with a download button, and Download .har above the trace saves the whole trace as one file. Long lists scroll inside their own box.

If a job pauses while talking to Planning Analytics#

A run that reads from IBM Planning Analytics (TM1) can seem stuck for a while. When Planning Analytics drops a session or reports that it is unavailable, Reportworq reconnects and tries the call again, up to three times, waiting about 10 seconds between tries. Each try is written to the run's log, so you can tell a job that is working through a hiccup from one that is truly stuck. Look for these entries in the job log under Advanced diagnostics:

• TM1 call failed, retrying (Warning). The call failed. The entry names the operation and server, says which retry this is (for example "retry 2 of 3"), and how long Reportworq waits before reconnecting.
• TM1 reconnect failed (Warning). The reconnect itself did not work, but Reportworq goes on with the next try anyway.
• TM1 call recovered after retry (Information). The call finally worked. This entry closes the retry entries and says how many tries it took and about how many seconds were lost. The job carries on normally, so a recovered pause needs no action, although repeated ones suggest the Planning Analytics server or network is unstable.
• TM1 call failed after 3 retries (Error). The tries ran out. Depending on the call, the affected values show an error, or the step fails. Check that the Planning Analytics server is up and reachable and that the connection still signs in, then run the job again.

Two of these entries are shown only when Verbose logging is on: TM1 call recovered after retry (a call that works after a retry is a success, so it is logged as information rather than a warning) and the note that a session is still valid. The retry, reconnect-failed and failed-after-3-retries entries are always written.

Common causes to check#

• A data source is unavailable or timed out. The log or the HTTP trace shows the failing call. Confirm the source system is up and the connection still works.
• A parameter resolved to nothing. A parameter value that returns no data can leave a run with no output. Check the parameter and its source query.
• No distributor for the output. A run can generate output but deliver nothing if the job has no configured distribution. Check the job's distribution.
• A missing or moved source file. If a source file was renamed or moved, re-link it in the job editor.
• The run succeeded but produced no output. Check sheet suppression and any exception-check send-gate on the job's worksheets, which can intentionally hold or empty the output.

Escalate to support#

Open the run and select Send to support in its header (it is also in the Actions menu) to upload the run's archive directly. You are asked to describe what you are sending, and you can add a support ticket number. Select Cancel and nothing is sent. To attach the logs to a ticket yourself instead, open the Actions menu and select Download history, which downloads the run's whole execution database as a .zip. If the upload cannot reach Reportworq support (the server may not have access to the internet), Reportworq says so and offers to download the same .zip for you to send.

If the log does not show enough to work with, re-run the job with Verbose logging on, and Trace logging as well when a data source is involved, then escalate that run. See Run a job.

Notes and limits#

The Trace tab is empty unless Trace logging was enabled at run time, and a log requires job-history logging to have been on for that run.

Going deeper. For symptom-to-fix guidance across the product, see the Troubleshooting index. A run that finished but took far too long is a different investigation, see Review a run's performance.