importer fails silently, seeming to succeed, when it has done nothing due to handler config

[ghost]

If users shoot themselves in the foot with a bad handler config (or if we shoot them in the foot with a bad default handler config, or documented handler config) then the UI seems to function as normal, the celery task reports success, etc. but nothing actually happens. For example, if there are no handlers or the handlers in the list are not actually doing anything, there is apparently nothing to detect and report that condition, so users simply see that importer did nothing while claiming to function as normal.

[davisc]

The are quite a few issues logged about the need to improve error handling to provide an improved user experience. A few thoughts I have are:

1. Allow celery tasks to be automatically retried for a configurable number of times if the original failure is not due to bad data. This assumes improving the way state is tracked. For example, when the Geoserver handler fails on the publish step because Geoserver is down - currently as a non developer, your only option is to try the upload process again when in fact all that is needed is for the task to pick up on that step and publish to Geoserver and GeoNode.
2. Have clear separation of upload from import. If the file upload is successful but import fails for whatever reason, the user shouldn't be required to upload the file again.
3. Error propagation should provide actionable information for the user or system admin;

[ghost]

I wrote this issue here specifically about what happens when there is e.g. an empty handler config, which is now the default after some recent changes that were wanted by the EventKit team. It's specifically about how this fails with bad handler configs, not silent failures more generally.

Task retries won't fix that particular problem, because an instance of importer started with a bad handler config will not "right itself" with the passage of time, retries, etc. The handler config has to be fixed and then a restart is needed to pick up the right handler config. The question is how the user knows that something is wrong, how they know what is wrong and how to fix it, if we are just silently pretending all is well.

If there are any more specific instances of silent failure, it would help to file those separately with specific repro instructions.