Description
As things stand right now, if you use any eligibility check via benefits.dmn's calculateBenefit decision service, then calculateBenefit will forgo running the actual check if a key matching the check's name is provided in the inputs.
The reason for this behavior is to prevent us having to define this default in every eligibility check itself.
This presents a problem, however, when calling eligibility checks outside the context of calculateBenefit (e.g. from another eligibility check). In this scenario, the actual check will be run, regardless of the inputs provided. This makes each check's behavior inconsistent.
Possible approach to fixing:
- Boilerplate: require each check to explicitly check for a key in the inputs that matches its name.
- Pros: simple, allows custom approach when appropriate
- Cons: have to remember the boilerplate, not DRY.
Is there any other way to approach? I considered just wrapping all calls to eligibility checks, so that the behavior of calculateBenefit would be universal, but this doesn't solve part of the issue, where there would be inconsistent behavior if both enrolledInSomeBenefit and notEnrolledInSomeBenefit keys existed in the inputs. (Maybe this isn't worth worrying about?).
related: should we standardize on supporting only enrolledInSomeBenefit keys in the inputs and ignore notEnrolledInSomeBenefit entirely?