Root > Basic procedures > Configuring sending report > Dealing with send failures

Dealing with send failures

Previous pageReturn to chapter overviewNext page   

You (as developer) is interested in getting as much bug reports as possible. First, you have to select a reliable send method for delivering reports from users to you. However, it may be not enough. Sending may fail for many reasons:

Unplugged network cable;
Turned off wi-fi;
Bad wi-fi signal strength;
Bad network settings (e.g. DNS, gateway, etc.);
Blocked by firewall;
Problems on ISP's side (maintenance, etc.);
Changed settings on your receiving side (e.g. you have closed account in your bug tracker);


Bug report will not reach you in all these cases. Then what?


Well, we have several techniques for dealing with network delivery problems.



Setting up fallback send methods

First, you may set up multiple send methods. You arrange them in a preferred order:



Two send methods were set up


EurekaLog will try to send report via first defined send method - say, a bug tracker (FogBugz in the screenshot example above). If sending fails for whatever reason - EurekaLog will attempt to send via next available send method (SMTP client in the screenshot example above). And so on - until send succeeds or no more send methods are set up.


Important Note: shell/mailto send method have no way to determinate if a send was completed successfully. Therefore, this method always return success. So next send method will never be called. For this reason, shell/mailto send method should always be last method to be used.


See also: advantages and disadvantages of each send method.



Recommended order of send methods

We recommend the following order:

1. The method of your choice (like HTTP or Web-tracker)
2. SMTP Server or SMTP Client (depending on whenever can you store your account details in application or not)
3. MAPI or Simple MAPI or both
4. Shell (mailto)


If you don't want (or can't) use some method in this list - just exclude it and place the rest in this order.


For example, if you want a reliable "mail only" delivery - use this:

1. SMTP Client
2. MAPI or Simple MAPI or both
3. Shell


If you can't afford storing password - use this:

1. SMTP Server
2. MAPI or Simple MAPI or both
3. Shell

(however, this has greater chances to fail sending)


This is just recommendation, not final rule. For example, you may use this sequence:

1. Mantis

2. Shell


It's your choice, it's up to you.


Note: usually there is no big reason to enable both SMTP client and SMTP server modes. Use either first or second, but not both. I.e. if you can afford storing the password from your real e-mail account in application - use SMTP client. Otherwise use SMTP server.



Saving bug report's backup

Second, if send fails (meaning all send methods) - EurekaLog may be set up to copy bug report file to My Documents folder. See "Save bug report copy to My Documents folder" option. The user will be notified about it (assuming you have set up a failure message to be visible). The idea is that user can pick up this file and send it to you (developer) manually via any available means. You may change backup file location and/or file name by using OnCustomFileName event handler (you are interested in AFileType = ftZIPCopy).


Additionally, report can be copied to the clipboard (both as file and as text simultaneously) - via "Copy bug report to clipboard" option. The idea is that user will be able to launch e-mail client (or go to support form on your web-site, etc.) and paste report into message.


Important Note: shell/mailto send method have no way to determinate if a send was completed successfully. Therefore, this method always return success. So fallback/recovery/saving will never be called. For this reason, we do not recommend to use shell/mailto send method, if you are going to use any of fallback/recovery methods.



Perform custom recovery

Finally, you may assign event handler to be called on send failure and perform you own custom actions (like saving bug report file to some sort of storage). For example, you may assign OnExceptionAction event handler and look for (AEurekaAction = atSent) and (AExecute = False). AAdditionalInfo will hold error message from sending. You may perform your recovery, and even switch AExecute to True to indicate successful send (so error message and creating backup will be skipped). If you did not alter "success" state of failed send - then OnExceptionError will be raised with AEurekaAction = stSent. You may perform your recovery there, and even swithc ARetry to True to retry sending.


See also: How to get file name for bug report?



Automatic resending of failed bug reports

EurekaLog do not have such feature, because of many implementation issues.


If send fails - EurekaLog can add report to some sort of offline storage. That is not an issue. Now, many questions arise:

How should EurekaLog  limit size of this storage?
How often should EurekaLog clean it?
What if application is uninstalled: who will clear the storage?
How uninstaller will know about EurekaLog's storage location?
Who and when will resend reports from storage?
Should EurekaLog resend on application's startup?
Should EurekaLog resend when another exception occur?
What if application is non-GUI?
What if startup time is important?
What if next exception never occur?
Should EurekaLog monitor network for availability?
Use task scheduler?
What if application is a DLL or COM object, e.g. it can not run by itself to resend reports?
If you will perform sending from another process - what about firewall? Your application may be allowed in firewall, while some random background process is not.
How EurekaLog may inform user that issue was fixed?


There are too many questions without good answers. That is why this aspect is currently left for your own implementation. You may create a subfolder in APPDATA folder; copy backups in that folder; resend when you can; may be create a standalone send application; clear subfolder when necessary. Refer to Implementing offline storage for bug reports article for a sample implementation.



See also:

Send feedback... Build date: 2022-03-28
Last edited: 2022-01-13
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: