Page MenuHomePhabricator

Default failure_limit needs to be None to fallback to 1
Needs ReviewPublic

Authored by Arlolra on Mar 7 2017, 7:33 PM.
Referenced Files
Unknown Object (File)
Mon, Sep 19, 6:54 PM
Unknown Object (File)
Jun 18 2022, 6:28 PM
Unknown Object (File)
Apr 11 2017, 9:07 PM
Unknown Object (File)
Apr 11 2017, 9:07 PM
Unknown Object (File)
Apr 4 2017, 5:52 AM
Unknown Object (File)
Mar 30 2017, 10:59 AM
Unknown Object (File)
Mar 8 2017, 9:44 AM


Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Patch without arc
git checkout -b D588 && curl -L | git apply

Diff Detail

Event Timeline

Restricted Application added a reviewer: Restricted Owners Package.Mar 7 2017, 7:33 PM
thcipriani added a subscriber: dduvall.

So contrary to the principal of least astonishment, setting the default failure_limit to None sets it to 1 due to;2c4894c1a1ec4cfdad3c5981325267ec434f7852$273

There is probably a bit of refactoring that ought to happen to make the default failure_limit be unset (which does seem to make sense in hindsight :)). @dduvall is definitely the person I'd defer to for opinions here.

Sounds good.

This patch was mainly about pointing out the inconsistency between the docs,

failure_limit [group]_failure_limit	1

and my experience,

Was this ever resolved? I remember another commit on this issue...