There seems to be internal confusion as to whether retry_count really means "tries", where 0--which is a legal value--means never try at all or "retries", where 0 means try once (but never "retry"). My assumption is that no one really intends to disable the action by setting retry_count=0.
This tries to clear that up by updating safe_to_snap() so retry_count=1 results in exactly 1 try and by modifying the default to be 2 so as to preserve the current default behavior. If preserving the number of retries that happen based on a particular input is more important, perhaps it would be best to just make retry_count=0 an illegal value.
I've also updated the help text for the --retry_count option for the singleton CLI tool to reflect that the max is 100 (not 3--I'm guessing this was a mixup between "max" and "default")
What this does
There seems to be internal confusion as to whether
retry_countreally means "tries", where 0--which is a legal value--means never try at all or "retries", where 0 means try once (but never "retry"). My assumption is that no one really intends to disable the action by settingretry_count=0.This tries to clear that up by updating
safe_to_snap()soretry_count=1results in exactly 1 try and by modifying the default to be 2 so as to preserve the current default behavior. If preserving the number of retries that happen based on a particular input is more important, perhaps it would be best to just makeretry_count=0an illegal value.I've also updated the help text for the
--retry_countoption for the singleton CLI tool to reflect that the max is 100 (not 3--I'm guessing this was a mixup between "max" and "default")