Request processing order
There are many functions and capabilities in A-Parser, and this diagram shows the order of processing a request from reading it from a file (or text) to saving the final result to a file.
Schematic order of request processing
Notes
- When filtering and deduplicating results, the entire request and its results are canceled if a simple result is used for comparison. If an array is used for comparison, the elements from that array are removed.
- Many steps in the diagram are optional and depend on the settings specified in the Task Editor.
- Additional requests may appear when using the Parse all result and Parse to level options. All additional requests have the following level relative to the request from which the additional requests were created, with the level counting starting from zero. That is, the original requests from the file or text always have level 0. Requests after substitutions also have level 0.
Failed requests
A request is considered failed and skipped if it cannot be executed within the specified number of attempts.
How to determine why a request failed? Enable logging or run a Task Test. All errors are logged. By studying the log, you can understand what went wrong.
An example of a failed request. The logs indicate that the request could not be executed due to a captcha, and the attempts have been exhausted. In this case, connecting a captcha solving service or increasing the number of attempts (only if you are scraping with proxies, otherwise increasing attempts is useless) may help.
How to increase the number of attempts? You need to override the Request retries option and set a higher value.
