12/19/2016 11:46:02 PM
in place) for existing tests
|
12/19/2016 10:54:52 PM
null field of type Integer, Enum, ... (in accordance with our existing default). See #678
* SafetyInitializer : Add new cases
* Fix existing broken catalogs (from previous commit 26e650f7) due to stricter catalog validation
|
|
|
12/19/2016 8:49:36 PM
handling. See #678
|
12/19/2016 1:33:39 PM
Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/19/2016 10:13:08 AM
should always sit at the same level or below corresponding
ADD items in the tree. Add sanity check for this and various tests around
repairs and overlapping periods.
See https://github.com/killbill/killbill/issues/664.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/16/2016 11:26:33 PM
See #678
|
|
|
|
|
12/16/2016 8:53:02 AM
the current behavior under atypical scenarios, namely:
* Complex timelines with various same-day changes do not trigger any bounds
* Duplicate (buggy) billing events do not lead to invoicing errors
* If multiple fixed items for a given subscription and start date already exist on disk, the next run will not re-generate one
* If multiple recurring items for a given subscription and service period already exist on disk, the next run will not complete (the merge logic will detect the existing bad state, i.e. double billing)
While the system can already handle these bad cases, it's still possible that either our items generation
code (proposed items) or the merge algorithm have issues in even more complex setups (repairs, adjustments, etc.).
To pro-actively detect these, this patch introduces new internal safety checks on the resulting list:
* At most one FIXED item should be present for a given subscription id and start date
* At most one RECURRING item should be present for a given subscription id and service period
The behavior can be disabled by setting org.killbill.invoice.sanitySafetyBoundEnabled=false.
See https://github.com/killbill/killbill/issues/664.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
