You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if a failure occurs during subsetting a granule file, it is ignored, and the granule is simply skipped. If the error is something that might impact every granule (e.g., a network error), it is possible for every granule to be "skipped" due to the error, thus resulting in an "empty" output.
Thus, in addition to logging each failed granule, we want to keep track of the total number of failed granules, and at the end of processing, log the total number of failed granules along with the total number of granules within the AOI/temporal range. This may help the user determine whether or not to rerun the job, based on the percentage of download failures. That is, if a very small number of granules failed to download, the user might decide that the output is still usable, and thus rerunning the job would be unnecessary.
Further, add a "tolerated_failure_percentage" input to allow users control over exactly when the subsetter aborts the job. The value (int/float in closed range [0, 100], clamped) indicates the percentage of granule failures to tolerate. For example, a value of 10 indicates that as soon as the subsetter exceeds 10 percent of the total number of granules fail to be processed, the subsetter will fail the job.
The default value for "tolerated_failure_percentage" should be 0, so we "fail fast."
The text was updated successfully, but these errors were encountered:
Currently, if a failure occurs during subsetting a granule file, it is ignored, and the granule is simply skipped. If the error is something that might impact every granule (e.g., a network error), it is possible for every granule to be "skipped" due to the error, thus resulting in an "empty" output.
Thus, in addition to logging each failed granule, we want to keep track of the total number of failed granules, and at the end of processing, log the total number of failed granules along with the total number of granules within the AOI/temporal range. This may help the user determine whether or not to rerun the job, based on the percentage of download failures. That is, if a very small number of granules failed to download, the user might decide that the output is still usable, and thus rerunning the job would be unnecessary.
Further, add a "tolerated_failure_percentage" input to allow users control over exactly when the subsetter aborts the job. The value (int/float in closed range [0, 100], clamped) indicates the percentage of granule failures to tolerate. For example, a value of 10 indicates that as soon as the subsetter exceeds 10 percent of the total number of granules fail to be processed, the subsetter will fail the job.
The default value for "tolerated_failure_percentage" should be 0, so we "fail fast."
The text was updated successfully, but these errors were encountered: