Error handling, filtering and reporting

[drws]

First, a few questions about --errors:

• Do --errors show errors, suppressed by ssl_no_verify/ignore_*/empty-diff/additions_only/deletions_only directives, possibly as warnings?
• Is all --errors logic and functionality also incorporated in a normal run? Are there any job-related errors that aren't reported through reporters?
• If webchanges is running successfully and one reads reports, is there no need to periodically run --errors for maintenance? Is --errors mode meant only for debugging?

--errors also produces a somewhat cryptic message:

Jobs with errors or returning no data (after unmodified filters, if any)

Jobs "returning no data after filtering" are not necessarily errors, they might be valid responses. Is this a bug in --errors?

What webchanges should possibly do is to warn about jobs that successfully fetch empty data and also warn about ones whose data gets emptied during filtering. These would be helpful warnings for normal and --errors modes, and could also be included in reports. Only the jobs that unsuccessfully return no/partial data have true show-stopping errors.

Also a somewhat related question, it is unclear in the documentation how exactly additions_only replaces semi-deprecated empty-diff? It seems both have their own purpose with only a partial overlap.

[mborsetti]

Hi @drws ,

Sorry for the delay. These are all great questions, and will update the help documents based on them.

• Do --errors show errors, suppressed by ssl_no_verify/ignore_*/empty-diff/additions_only/deletions_only directives, possibly as warnings?

It runs the data ingestion part of the job as specified and flags, using text, any error that would take place during execution, even if suppressed, plus any jobs that produces no output. Note that ssl_no_verify does not throw errors (but it is applied) and empty-diff is irrelevant (no diffing is made, only filtering).

It is a maintenance tool to detect situations that one may not be aware of, typically driven by undetected changes in the source. The user may have missed the alert when all the content went away or is applying filters to the diff.

• Is all --errors logic and functionality also incorporated in a normal run? Are there any job-related errors that aren't reported through reporters?

Yes, but --errors shows errors that are below the max_tries threshold, who are suppressed by a ignore_* directive, and alerts if the filter produces empty data (which may or may not be desired).

• If webchanges is running successfully and one reads reports, is there no need to periodically run --errors for maintenance? Is --errors mode meant only for debugging?

If everything is set up 100% correctly, and you catch the notification that all of your content has disappeared (because, e.g., a web page was redesigned and your xpath/css filter now returns nothing), then no, there's no need. Personally, and for my use, I find it a maintenance tool, not just for debugging, and run --errors periodically to catch anything that is askew.

Jobs "returning no data after filtering" are not necessarily errors, they might be valid responses. Is this a bug in --errors?

Great feedback. Indeed, it's only warning about jobs returning no data after filtering, as that may be a valid response.

What webchanges should possibly do is to warn about jobs that successfully fetch empty data and also warn about ones whose data gets emptied during filtering. These would be helpful warnings for normal and --errors modes, and could also be included in reports. Only the jobs that unsuccessfully return no/partial data have true show-stopping errors.

I can't think of instances where the source stops sending data (without also throwing a 500 or similar HTTP error) all of a sudden; IME most issues derive from changes in the data source that causes filters to delete all the data. So while this change makes sense, probably not high on the list.

Also a somewhat related question, it is unclear in the documentation how exactly additions_only replaces semi-deprecated empty-diff? It seems both have their own purpose with only a partial overlap.

empt-diff is cruder, applies to all jobs (not job-by-job), and simply suppresses the reporting of diff that becomes empty after filtering. additions_only offer enhanced functionality as is per-job, reshapes the diff to additions-only on a line-by-line basis, and has a safeguard for large drops.