Job waiting on after script when it shouldn't

[sfc_scottr]

I recently upgraded from version 7 to 9.39 and migrated all the existing jobs. Some of the jobs included an "after" script to be run. For these jobs this command looks like:
#HTTP GET www.somedomain.com/somepath

This script is built to parse the Syncovery log file for the job that calls it and handle some extra file work that's needed. The script waits for the log file name to updated to include the word "copied" as an indicator the job is complete. If it doesn't find the file, it waits for a few seconds and tries again. If no file is still found, it exits with an error.

Under version 7, this seemed to work as expected: the job would copy the files, call the external script (not wait), and finish updating/renaming the log file. The script would then read the log file and do its thing. But since the upgrade the script started failing when called directly from Syncovery. I confirmed the script is successfully being called, it just can't find the indicated log file with "copied" in its name and is thus exiting with an error. If I copy/paste the intended script and run it manually, it runs exactly as expected.

It seems that even though the script setting starts with # the job is waiting until the external script finishes before completing the updates to the log file. So when the script tries to find the target file, it doesn't exist.

Is this the correct behavior for scripts, even with the #? Is there some other setting I should be looking at? I compared all the settings from version to version but maybe I missed something?

[tobias]

Hello,
the # does not have any effect for HTTP GET. HTTP GET is always a synchronous request.

I can confirm that the result summary is not added to the log file name at the time the "Execute after" command is called. Maybe this has changed at some point in the last years.

So you just have to refrain from looking for the word "copied" in the log file name.

Alternatively, you could write a BAT file or other script to make the HTTP request, for example using CURL.

If you invoke a BAT file or other local script, then the # will have an effect.

[sfc_scottr]

Thanks for the info tobias. I appreciate the suggestions but I believe I'll need to go a different route to process the log and accomplish the need.

[tobias]

Hello,
if it helps I could probably enable the # to have an effect on HTTP GET, i.e. it would be launched in a separate thread, the result of HTTP GET would not be logged, and the profile would complete and rename its log file before even the HTTP GET finishes.

Should I do that in the next update?