Troubleshooting re-submit request errors in NexJ CRM
Re-submit request errors are clearly visible to users in NexJ CRM and typically occur sporadically and may not be consistently reproducible.
Re-submit request errors contain a Re-submit request button and a multipart hexadecimal error code that you can parse for troubleshooting purposes.
The following is an example of a re-submit request error message:
An unexpected error occurred while attempting to communicate with the server Please try again after a few moments. (fr15439fa0209gdef31).
Typical causes
Re-submit request errors are typically caused by a communication problem between a user's browser and the web server, such as a network connection interruption. Re-submit request errors are also caused by inconsistent web tier configuration across the cluster nodes, for example, inconsistent configuration of session cookies.
Information to collect
Collect the following information to assist with troubleshooting:
- Screenshots, timestamps, and login IDs of affected users
- The decoded WinInet or HTTP status code from the hexadecimal reference code
- The decoded timestamp from the hexadecimal reference code
- A Fiddler or browser-generated HTTP trace, if required
Troubleshooting
Parse the reference code from the error message. In the reference code, the value between fr and gd is the hexidecimal value of the date and time that the error occurred in milliseconds. For example, for the fr15439fa0209gdef31 reference code, you can use a UNIX epoch time converter to convert 15439fa0209 to April 21, 2016 5:59:26.473 PM.
The value between gd and i is the hexidecimal value of the error code. Typically, 5-digit codes are WinInet error codes and 3-digit codes are HTTP status codes such as 403 errors. For example, the 2ef3 hexidecimal value represents a WinInet error, where 2ef3 converts to 12019 in decimal and to the ERROR_INTERNET_INCORRECT_HANDLE_STATE Winlnet error.
For nontrivial errors:
- Use Fiddler, Chrome DevTools, or Internet Explorer Developer Tools to capture a trace of HTTP traffic while reproducing the issue. Then, look for abnormal HTTP status codes, Set-Cookie responses, or authentication prompts.
- Review the web server access and error logs.
- If your environment uses WebSphere Application Server (WAS), ensure that WAS plugin configuration is identical on all web server nodes.
- Ensure that there are no issues with network stability, including packet loss or abnormal transfer and response times.
Re-submit request errors occur inside the client framework code loaded in the browser and will not be output in the server logs.