Web Report Viewer Troubleshooting

Ckaup — Wed, 13 May 2026 20:45:03 GMT

Common Errors (Table Mode)

← Older revision		Revision as of 15:45, 13 May 2026
(9 intermediate revisions by the same user not shown)
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.

			=== 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.

	=== Why can't web work the same way as desktop? ===		=== Why can't web work the same way as desktop? ===
Line 45:		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.

			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>.

			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. 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 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? ====

			"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>.

	=== How is Report Queue, the Python application, involved in this? ===		=== How is Report Queue, the Python application, involved in this? ===
Line 100:		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.
	\|}		\|}

Line 193:		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 ==

ITrack/Pro/Credits

Hhovland — Fri, 24 Apr 2026 17:00:10 GMT

Current

← Older revision		Revision as of 12:00, 24 April 2026
(2 intermediate revisions by the same user not shown)
Line 15:		Line 15:
	* [[Josh Duff]]		* [[Josh Duff]]
	* [[Steven Patras]]		* [[Steven Patras]]
			* [[Justin McKinstry]]

	==== Current ====		==== Current ====
	* [[Dayton Lowell]]		* [[Dayton Lowell]]
	* [[Dillon Sadofsky]]		* [[Dillon Sadofsky]]
	* ~~[[Justin McKinstry]]~~		* Harrison Hovland

	== Open Source Software ==		== Open Source Software ==

Web Report Viewer Troubleshooting

Ckaup — Tue, 21 Apr 2026 18:31:40 GMT

Common Errors (Table Mode)

← Older revision		Revision as of 13:31, 21 April 2026
Line 92:		Line 92:
	\|\| (I can't remember the error message) \|\| Missing / invalid ODBC configuration. I think this presents as "could not connect to the database" or something to that effect. Sometimes it'll give you a "database vendor code" just like ITrack desktop. \|\| Depending on the error code, Brian can make sure the ODBC connection is valid, and give Charles the name to check that the ODBC connection name in the Crystal Server config is correct. But some error codes like 1064 are unrelated to the odbc setup		\|\| (I can't remember the error message) \|\| Missing / invalid ODBC configuration. I think this presents as "could not connect to the database" or something to that effect. Sometimes it'll give you a "database vendor code" just like ITrack desktop. \|\| Depending on the error code, Brian can make sure the ODBC connection is valid, and give Charles the name to check that the ODBC connection name in the Crystal Server config is correct. But some error codes like 1064 are unrelated to the odbc setup
	\|-		\|-
	\|\| Invalid Report \|\| The Crystal Server failed to find the report with the specified name/type. \|\| Make sure the report exists in the customer database with the given name and type, and a valid <code>report.fileid</code>. In Presage, there used to be a bug where running reports with a non-English language selected would fail with this error.		\|\| "Invalid Report" or "No report found of type <type> and name <name>" \|\| The Crystal Server failed to find the report with the specified name/type. \|\| Make sure the report exists in the customer database with the given name and type, and a valid <code>report.fileid</code>. In Presage, there used to be a bug where running reports with a non-English language selected would fail with this error.
	\|-		\|-
	\|\| The file or directory is corrupted and unreadable \|\| This would come up every so often because the D drive on Bunnahabhain was failing. It shouldn't happen anymore. \|\| It shouldn't happen again, but if it does, delete the cached report file from <code>M:\report_cache</code> on Bunnahabhain. Maybe reupload the report if it persists after that.		\|\| The file or directory is corrupted and unreadable \|\| This would come up every so often because the D drive on Bunnahabhain was failing. It shouldn't happen anymore. \|\| It shouldn't happen again, but if it does, delete the cached report file from <code>M:\report_cache</code> on Bunnahabhain. Maybe reupload the report if it persists after that.

Internal:Aggregator Ebay Plugin

Rmccown — Thu, 16 Apr 2026 19:01:55 GMT

File:EbayOAuthFlow.png

Rmccown — Thu, 16 Apr 2026 18:59:34 GMT

Rmccown uploaded File:EbayOAuthFlow.png chromium to ebay oauth flow

New page

== Summary ==
chromium to ebay oauth flow

ISoft Wiki - Recent changes [en]

Web Report Viewer Troubleshooting

ITrack/Pro/Credits

Web Report Viewer Troubleshooting

Internal:Aggregator Ebay Plugin

File:EbayOAuthFlow.png