DayCuts
02-24-2015, 01:57 AM
Hi bigstar, have encountered an issue with some custom commands that is likely related to the error fail-safe recently introduced. Tested on build 3808.
I have a custom command that recurses some directories and cleans up some old or unwanted files (using /select and /delete selected). It does some other stuff as well but it is only the delete operations that seem to be affected here.
If I have a previously failed transfer (eg a folder manually marked as failed) at the top of the queue then any delete operation added after it in the queue is not processed. I assume this is a side affect of the fail-safe that was put in place however it doesn't stop the entire queue, it only marks the delete operations as failed when it gets to them and continues with anything else (in my case there are also raw commands, mkdir, etc interspersed which are still processed). There is nothing in the log related to the delete operations and the queue is not stopped as would be expected by the fail-safe behavior.
I accept that having failed items already in the queue can complicate things and it is my responsibility to use custom command appropriately knowing this (always remember to open a new session). It does however point to unexpected and inconsistent behavior of the fail-safe. It may be worth mentioning that in my custom command I do not initiate the queue. I let it run to queue all the operations than review it before starting the queue (as I am still refining these particular commands).
Doing some testing I confirmed that everything functions as expected if I do not have those queue items already marked as failed.
A. If those failed items are at the top then they are left alone (failed) and all following delete operations are not processed (marked failed as it gets to them) but the queue is never stopped as might be expected if the command execution fail-safe is triggered.
B. If those failed items are anywhere else in the queue (middle for example, manually moved down for testing purposes) then they seem to be reset (no longer marked failed) when the queue begins. The queue then processed normally. If those items then fail (in my case they were folders queued for download that had been moved awaiting me to correct/requeue, so they did fail) they are of course marked as failed then the behavior continues as described in A above. This 'reset' does not occur if the failed items are at the top, confirmed by the status log not attempting to process them. I am assuming that this behavior is also tried to the fail-safe, perhaps resetting so that flashfxp can fully attempt to process a queue it thinks is entirely related to the custom command.
In short the issues I see here are...
1. Under these circumstances the fail-safe seems inconsistent as only delete operations are marked failed (no attempt to process) while the rest are performed. This could cause issues if other queue operations rely on on those files being removed (eg upload a new version, or move/rename another file to that filename/location). Given avoiding such potential problems was the point of the fail-safe it should cease processing the queue entirely.
2. It seems unwise that any items marked as failed should be reset, regardless of position, if there are un-failed items in the queue. I have not noticed this behavior in a regular transfer-only queue, only during custom commands that add non-transfer queue items. I have also not tested if this is a wider queue-reset behavior issue that would do the same if I had manually added a non-transfer queue item to a list of failed transfer items as I do not have time at the moment. My guess is that this is in fact a wider issue related to the reset behavior of the queue that may not be taking non-transfer items into consideration when determining if the queue should be reset, but the different behavior depending on the position of the items makes this unclear. Again I have not tested but my guess is that any transfer items are the top would remain un-reset, but any further down (after the first non-transfer item) would likely be reset. Will look closer at this when I have some more time.
Again, clearly I need to remember to always use a fresh session, but the above behaviors could just as easily arise in a clean session using custom commands that use both transfer and non-transfer operations (eg if a transfer operation fails at some stage it will then cause behavior B, rather than stop entirely).
I have a custom command that recurses some directories and cleans up some old or unwanted files (using /select and /delete selected). It does some other stuff as well but it is only the delete operations that seem to be affected here.
If I have a previously failed transfer (eg a folder manually marked as failed) at the top of the queue then any delete operation added after it in the queue is not processed. I assume this is a side affect of the fail-safe that was put in place however it doesn't stop the entire queue, it only marks the delete operations as failed when it gets to them and continues with anything else (in my case there are also raw commands, mkdir, etc interspersed which are still processed). There is nothing in the log related to the delete operations and the queue is not stopped as would be expected by the fail-safe behavior.
I accept that having failed items already in the queue can complicate things and it is my responsibility to use custom command appropriately knowing this (always remember to open a new session). It does however point to unexpected and inconsistent behavior of the fail-safe. It may be worth mentioning that in my custom command I do not initiate the queue. I let it run to queue all the operations than review it before starting the queue (as I am still refining these particular commands).
Doing some testing I confirmed that everything functions as expected if I do not have those queue items already marked as failed.
A. If those failed items are at the top then they are left alone (failed) and all following delete operations are not processed (marked failed as it gets to them) but the queue is never stopped as might be expected if the command execution fail-safe is triggered.
B. If those failed items are anywhere else in the queue (middle for example, manually moved down for testing purposes) then they seem to be reset (no longer marked failed) when the queue begins. The queue then processed normally. If those items then fail (in my case they were folders queued for download that had been moved awaiting me to correct/requeue, so they did fail) they are of course marked as failed then the behavior continues as described in A above. This 'reset' does not occur if the failed items are at the top, confirmed by the status log not attempting to process them. I am assuming that this behavior is also tried to the fail-safe, perhaps resetting so that flashfxp can fully attempt to process a queue it thinks is entirely related to the custom command.
In short the issues I see here are...
1. Under these circumstances the fail-safe seems inconsistent as only delete operations are marked failed (no attempt to process) while the rest are performed. This could cause issues if other queue operations rely on on those files being removed (eg upload a new version, or move/rename another file to that filename/location). Given avoiding such potential problems was the point of the fail-safe it should cease processing the queue entirely.
2. It seems unwise that any items marked as failed should be reset, regardless of position, if there are un-failed items in the queue. I have not noticed this behavior in a regular transfer-only queue, only during custom commands that add non-transfer queue items. I have also not tested if this is a wider queue-reset behavior issue that would do the same if I had manually added a non-transfer queue item to a list of failed transfer items as I do not have time at the moment. My guess is that this is in fact a wider issue related to the reset behavior of the queue that may not be taking non-transfer items into consideration when determining if the queue should be reset, but the different behavior depending on the position of the items makes this unclear. Again I have not tested but my guess is that any transfer items are the top would remain un-reset, but any further down (after the first non-transfer item) would likely be reset. Will look closer at this when I have some more time.
Again, clearly I need to remember to always use a fresh session, but the above behaviors could just as easily arise in a clean session using custom commands that use both transfer and non-transfer operations (eg if a transfer operation fails at some stage it will then cause behavior B, rather than stop entirely).