Web Report Viewer Troubleshooting - Revision history

Ckaup: /* Common Errors (Table Mode) */

2026-05-13T20:45:03Z

Common Errors (Table Mode)

← Older revision		Revision as of 15:45, 13 May 2026
Line 130:		Line 130:
	\|\| <code>Database Vendor Code (code)</code> \|\| There was some MySQL error. Look up the error code. \|\| Might depend on the error code, but it's probably because of a bad query in the report. Reupload report. If some parameters are missing or blank, there could have been an issue running a report parameter query, and omitting those parameters could have caused a syntax error (1064)		\|\| <code>Database Vendor Code (code)</code> \|\| There was some MySQL error. Look up the error code. \|\| Might depend on the error code, but it's probably because of a bad query in the report. Reupload report. If some parameters are missing or blank, there could have been an issue running a report parameter query, and omitting those parameters could have caused a syntax error (1064)
	\|-		\|-
	\|\| <code>Internal Server Error</code> \|\| Either you're on a version of EEW that doesn't forward the error to the client properly, or you encountered an error that is not properly handled by Crystal Server \|\| Check Report Viewer > History to see the actual error, or if that fails, the Crystal Server logs~~. If the error is <code>WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.</code> and you're connecting to a MySQL 8 DB, turn that setting off~~.		\|\| <code>Internal Server Error</code> \|\| Either you're on a version of EEW that doesn't forward the error to the client properly, or you encountered an error that is not properly handled by Crystal Server \|\| Check Report Viewer > History to see the actual error, or if that fails, the Crystal Server logs.
	\|}		\|}

Ckaup: /* Configuration */

2026-05-13T20:43:51Z

Configuration

← Older revision		Revision as of 15:43, 13 May 2026
Line 223:		Line 223:

	If they're self hosted, and don't want to use our Crystal Server, follow the steps under "Deployment", then set the above ENV variables to the proper values for their setup.		If they're self hosted, and don't want to use our Crystal Server, follow the steps under "Deployment", then set the above ENV variables to the proper values for their setup.

			=== Updating a Client to MySQL 8 ===

			When a client's database is updated to MySQL 8, the MySQL connector 5.3 will no longer work. Update their ODBC to use the MySQL 8.0 Unicode driver, and turn off "Enable automatic reconnect"

	== Updating ==		== Updating ==

Ckaup: /* Common Errors (Table Mode) */

2026-05-13T20:40:00Z

Common Errors (Table Mode)

← Older revision		Revision as of 15:40, 13 May 2026
Line 130:		Line 130:
	\|\| <code>Database Vendor Code (code)</code> \|\| There was some MySQL error. Look up the error code. \|\| Might depend on the error code, but it's probably because of a bad query in the report. Reupload report. If some parameters are missing or blank, there could have been an issue running a report parameter query, and omitting those parameters could have caused a syntax error (1064)		\|\| <code>Database Vendor Code (code)</code> \|\| There was some MySQL error. Look up the error code. \|\| Might depend on the error code, but it's probably because of a bad query in the report. Reupload report. If some parameters are missing or blank, there could have been an issue running a report parameter query, and omitting those parameters could have caused a syntax error (1064)
	\|-		\|-
	\|\| <code>Internal Server Error</code> \|\| ~~You~~'re ~~probably~~ on a version of EEW that doesn't forward the error to the client properly. \|\| Check Report Viewer > History to see the actual error		\|\| <code>Internal Server Error</code> \|\| Either you're on a version of EEW that doesn't forward the error to the client properly, or you encountered an error that is not properly handled by Crystal Server \|\| Check Report Viewer > History to see the actual error, or if that fails, the Crystal Server logs. If the error is <code>WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.</code> and you're connecting to a MySQL 8 DB, turn that setting off.
	\|}		\|}

Ckaup: /* Can we make the timeouts longer? */

2026-05-06T20:39:52Z

Can we make the timeouts longer?

← Older revision		Revision as of 15:39, 6 May 2026
Line 73:		Line 73:
	Well, it's complicated. Currently the only timeouts at play are the VM-level and Web-container-level NGINX timeouts. So while those ''can'' be raised, it will be raised for ''every request to the API'', including requests that we'd prefer to time out at 60 seconds. If that's an acceptable tradeoff for your product, then the NGINX timeout can be raised ''for all GraphQL requests''.		Well, it's complicated. Currently the only timeouts at play are the VM-level and Web-container-level NGINX timeouts. So while those ''can'' be raised, it will be raised for ''every request to the API'', including requests that we'd prefer to time out at 60 seconds. If that's an acceptable tradeoff for your product, then the NGINX timeout can be raised ''for all GraphQL requests''.

	We could come up with a way to time out ~~other~~ requests early, whether that's by creating a custom plugin for our GraphQL client (Houdini) or by adding something to the API servers that can know to time some requests out at 300s and some at 60s, but we haven't done anything like that yet.		We could come up with a way to time out non-report GraphQL requests early, whether that's by creating a custom plugin for our GraphQL client (Houdini) or by adding something to the API servers that can know to time some requests out at 300s and some at 60s, but we haven't done anything like that yet.

	==== Why does it sometimes take a few minutes for a timed-out report preview to show in the "History" tab? ====		==== Why does it sometimes take a few minutes for a timed-out report preview to show in the "History" tab? ====

Ckaup: /* Why do I sometimes get "504 Gateway Timeout" when running a report in web? */

2026-05-06T20:39:18Z

Why do I sometimes get "504 Gateway Timeout" when running a report in web?

← Older revision		Revision as of 15:39, 6 May 2026
Line 57:		Line 57:
	=== Why do I sometimes get "504 Gateway Timeout" when running a report in web? ===		=== Why do I sometimes get "504 Gateway Timeout" when running a report in web? ===

	As outlined above, there are multiple web servers involved in the process of generating a PDF from a Crystal Report in the web, and each one of them has their own server-level timeouts. The web server connecting you to the application API (Chromium, Presage API, EE API) might time you out, and so might the web server connecting the application API to the Crystal Server.		As outlined above, there are multiple web servers involved in the process of generating a PDF from a Crystal Report in the web, and each one of them has their own server-level timeouts. The web server(s) connecting you to the application API (Chromium, Presage API, EE API) might time you out, and so might the web server connecting the application API to the Crystal Server.

	The NGINX default timeout is 60 seconds, and it's expected that some reports will take longer than this. More on this later.		The NGINX default timeout is 60 seconds, and it's expected that some reports will take longer than this. More on this later.

Ckaup: /* Why do I sometimes get "504 Gateway Timeout" when running a report in web? */

2026-05-06T20:36:48Z

Why do I sometimes get "504 Gateway Timeout" when running a report in web?

← Older revision		Revision as of 15:36, 6 May 2026
Line 61:		Line 61:
	The NGINX default timeout is 60 seconds, and it's expected that some reports will take longer than this. More on this later.		The NGINX default timeout is 60 seconds, and it's expected that some reports will take longer than this. More on this later.

	Presage Web has set its internal NGINX <code>proxy_read_timeout</code> to <code>300s</code>, meaning any and all requests to the API will time out at 300s instead of the default of 60s. However, the VM-level NGINX also defaults to <code>proxy_read_timeout</code> to <code>~~300s~~</code> and if that's not raised, then the VM-level NGINX will time out before the Web-level NGINX hits its timeout.		Presage Web has set its internal NGINX <code>proxy_read_timeout</code> for <code>/graphql</code> to <code>300s</code>, meaning that any and all requests to the API will time out at 300s instead of the default of 60s. However, the VM-level NGINX also defaults <code>proxy_read_timeout</code> to <code>60s</code> and if that's not raised, then the VM-level NGINX will time out before the Web-level NGINX hits its timeout.

	Currently EE API uses the default <code>proxy_read_timeout</code> of <code>60s</code>.		Currently EE API uses the default <code>proxy_read_timeout</code> of <code>60s</code>.
Line 71:		Line 71:
	==== Can we make the timeouts longer? ====		==== Can we make the timeouts longer? ====

	Well, it's complicated. Currently the only timeouts at play are the VM-level and Web-container-level NGINX timeouts. So while those ''can'' be raised, it will be raised for ''every request to the API'', including requests that we'd prefer to time out at 60 seconds.		Well, it's complicated. Currently the only timeouts at play are the VM-level and Web-container-level NGINX timeouts. So while those ''can'' be raised, it will be raised for ''every request to the API'', including requests that we'd prefer to time out at 60 seconds. If that's an acceptable tradeoff for your product, then the NGINX timeout can be raised ''for all GraphQL requests''.

	We could come up with a way to time out other requests early, whether that's by creating a custom plugin for our GraphQL client (Houdini) or by adding something to the API servers that can know to time some requests out at 300s and some at 60s, but we haven't done anything like that yet.		We could come up with a way to time out other requests early, whether that's by creating a custom plugin for our GraphQL client (Houdini) or by adding something to the API servers that can know to time some requests out at 300s and some at 60s, but we haven't done anything like that yet.
Line 77:		Line 77:
	==== Why does it sometimes take a few minutes for a timed-out report preview to show in the "History" tab? ====		==== Why does it sometimes take a few minutes for a timed-out report preview to show in the "History" tab? ====

	"Web Preview" jobs are only logged to the <code>reportqueue</code> table after ~~they are finished~~. If your ~~job~~ timed out at 60 seconds, then the request from the web client to the API likely timed out, meaning the API is still waiting for a response from Crystal Server. Since ~~it's~~ still waiting ~~for its request to complete~~, it will either create the <code>reportqueue</code> row after the report finishes, or once the request from API -> Crystal Server times out. And when the request from the client -> API times out, the API doesn't know about it - so it's possible for the <code>reportqueue</code> row to report no errors if the report finishes running before the request from API -> Crystal Server times out. Timeouts like this will probably come with the error <code>Failed to fetch: server returned invalid response with error 504: Gateway Time-out</code> in EEW/Presage Web, as that's what's returned from our GraphQL client when it hits a timeout. ~~And since the~~		"Web Preview" jobs are only logged to the <code>reportqueue</code> table after the API receives a response from Crystal Server. If your preview timed out at 60 seconds, then the request from the web client to the API likely timed out, meaning the API is still waiting for a response from Crystal Server. Since the API is still waiting, it will either create the <code>reportqueue</code> row after the report finishes, or once the request from API -> Crystal Server times out, whichever happens first. And when the request from the client -> API times out, the API doesn't know about it - so it's possible for the <code>reportqueue</code> row to report no errors if the report finishes running before the request from API -> Crystal Server times out. Timeouts like this will probably come with the error <code>Failed to fetch: server returned invalid response with error 504: Gateway Time-out</code> in EEW/Presage Web, as that's what's returned from our GraphQL client when it hits an NGINX timeout.

	If the request from the API -> Crystal Server is the first to time out, the API will catch the timeout error and return a GraphQL error to the client. In this case, since the error was caught by the API, it will immediately log to <code>reportqueue</code>.		If the request from the API -> Crystal Server is the first to time out, the API will catch the timeout error and return a GraphQL error to the client. In this case, since the error was caught by the API, it will immediately log to <code>reportqueue</code>.

Ckaup: /* Why do I sometimes get "504 Gateway Timeout" when running a report in web? */

2026-05-06T20:33:07Z

Why do I sometimes get "504 Gateway Timeout" when running a report in web?

← Older revision		Revision as of 15:33, 6 May 2026
Line 74:		Line 74:

	We could come up with a way to time out other requests early, whether that's by creating a custom plugin for our GraphQL client (Houdini) or by adding something to the API servers that can know to time some requests out at 300s and some at 60s, but we haven't done anything like that yet.		We could come up with a way to time out other requests early, whether that's by creating a custom plugin for our GraphQL client (Houdini) or by adding something to the API servers that can know to time some requests out at 300s and some at 60s, but we haven't done anything like that yet.


	==== Why does it sometimes take a few minutes for a timed-out report preview to show in the "History" tab? ====		==== Why does it sometimes take a few minutes for a timed-out report preview to show in the "History" tab? ====

Ckaup: /* Why do I sometimes get "504 Gateway Timeout" when running a report in web? */

2026-05-06T20:32:51Z

Why do I sometimes get "504 Gateway Timeout" when running a report in web?

← Older revision		Revision as of 15:32, 6 May 2026
Line 57:		Line 57:
	=== Why do I sometimes get "504 Gateway Timeout" when running a report in web? ===		=== Why do I sometimes get "504 Gateway Timeout" when running a report in web? ===

	As outlined above, there are multiple web servers involved in the process of generating a PDF from a Crystal Report in the web, and each one of them has their own server-level timeouts. The web server connecting you to the application API (Chromium, Presage API, EE API) might time you out, and so might the web server connecting the application API to the Crystal Server.		As outlined above, there are multiple web servers involved in the process of generating a PDF from a Crystal Report in the web, and each one of them has their own server-level timeouts. The web server connecting you to the application API (Chromium, Presage API, EE API) might time you out, and so might the web server connecting the application API to the Crystal Server.

			The NGINX default timeout is 60 seconds, and it's expected that some reports will take longer than this. More on this later.

			Presage Web has set its internal NGINX <code>proxy_read_timeout</code> to <code>300s</code>, meaning any and all requests to the API will time out at 300s instead of the default of 60s. However, the VM-level NGINX also defaults to <code>proxy_read_timeout</code> to <code>300s</code> and if that's not raised, then the VM-level NGINX will time out before the Web-level NGINX hits its timeout.

			Currently EE API uses the default <code>proxy_read_timeout</code> of <code>60s</code>.

			I do not know what timeouts are at play for Chromium since it uses a socket server instead of a GraphQL server like Presage Web and EEW do.

			Requests to Crystal Server on Bunnahabhain currently time out at 4m, so provided that the web client -> API timeout is longer than that (such as 5m), the API can catch the timeout error and return a more user-readable error to the client as is the case in Presage API.

	==== Can we make the timeouts longer? ====		==== Can we make the timeouts longer? ====

	~~The short answer is "not really"~~. ~~Since~~ the timeouts are at the ~~web server~~ level ~~(i.e~~., ~~nginx/Apache) all~~ requests to ~~that server have the same timeout~~. We could ~~decide not~~ to time ~~any request~~ out ~~until several minutes have passed~~, but if a request is ~~taking that long~~, it ''~~should~~'' time out.		Well, it's complicated. Currently the only timeouts at play are the VM-level and Web-container-level NGINX timeouts. So while those ''can'' be raised, it will be raised for ''every request to the API'', including requests that we'd prefer to time out at 60 seconds.

			We could come up with a way to time out other requests early, whether that's by creating a custom plugin for our GraphQL client (Houdini) or by adding something to the API servers that can know to time some requests out at 300s and some at 60s, but we haven't done anything like that yet.


			==== Why does it sometimes take a few minutes for a timed-out report preview to show in the "History" tab? ====

			"Web Preview" jobs are only logged to the <code>reportqueue</code> table after they are finished. If your job timed out at 60 seconds, then the request from the web client to the API likely timed out, meaning the API is still waiting for a response from Crystal Server. Since it's still waiting for its request to complete, it will either create the <code>reportqueue</code> row after the report finishes, or once the request from API -> Crystal Server times out. And when the request from the client -> API times out, the API doesn't know about it - so it's possible for the <code>reportqueue</code> row to report no errors if the report finishes running before the request from API -> Crystal Server times out. Timeouts like this will probably come with the error <code>Failed to fetch: server returned invalid response with error 504: Gateway Time-out</code> in EEW/Presage Web, as that's what's returned from our GraphQL client when it hits a timeout. And since the

			If the request from the API -> Crystal Server is the first to time out, the API will catch the timeout error and return a GraphQL error to the client. In this case, since the error was caught by the API, it will immediately log to <code>reportqueue</code>.

	=== How is Report Queue, the Python application, involved in this? ===		=== How is Report Queue, the Python application, involved in this? ===

Ckaup: /* FAQ */

2026-04-30T19:23:42Z

FAQ

← Older revision		Revision as of 14:23, 30 April 2026
Line 31:		Line 31:
	ITrack desktop talks directly to the Crystal Reports SDK on the individual workstation, instead of sending report jobs to a central server (Bunnahabhain) running Crystal Server. Crystal Server then uses Report Commander to create the PDF.		ITrack desktop talks directly to the Crystal Reports SDK on the individual workstation, instead of sending report jobs to a central server (Bunnahabhain) running Crystal Server. Crystal Server then uses Report Commander to create the PDF.

	=== Can web report viewer ~~print at~~ different sizes? ===		=== What is handled by Crystal Server and what is handled by Report Queue? ===

			Report Queue and Crystal Server are two separate systems that do not interact, so it's important to understand the boundaries between them.

			Crystal Server generates PDFs that can be viewed in a web browser. Crystal Server only generates the PDF, but it's typically displayed in either the "Report Viewer" screen, or in the "Send Report" modal in the application that requested it.

			Report Queue handles emailing and printing of reports. In the web, you can print/email using Report Queue by selecting "Printer" or "Email" in the "Send Report" modal.

			=== Can Crystal Server (web report viewer) generate PDFs of different sizes? ===

	Unfortunately not. Report PDFs created by Crystal Server are always letter size. Note that this only applies to report previews; if the customer has a Report Queue instance they can email or print a report of a different size that way.		Unfortunately not. Report PDFs created by Crystal Server are always letter size. Note that this only applies to report previews; if the customer has a Report Queue instance they can email or print a report of a different size that way.

Ckaup: /* FAQ */

2026-04-30T19:14:24Z

FAQ

← Older revision		Revision as of 14:14, 30 April 2026
Line 29:		Line 29:
	==== How is that different from desktop? ====		==== How is that different from desktop? ====

	ITrack desktop talks directly to the Crystal Reports SDK on the individual workstation, instead of sending report jobs to a central server (Bunnahabhain) running Crystal Server.		ITrack desktop talks directly to the Crystal Reports SDK on the individual workstation, instead of sending report jobs to a central server (Bunnahabhain) running Crystal Server. Crystal Server then uses Report Commander to create the PDF.

			=== Can web report viewer print at different sizes? ===

			Unfortunately not. Report PDFs created by Crystal Server are always letter size. Note that this only applies to report previews; if the customer has a Report Queue instance they can email or print a report of a different size that way.

	=== Why can't web work the same way as desktop? ===		=== Why can't web work the same way as desktop? ===