CI randomly failing with debts.solver.UnbalancedRequest

[JocelynDelalande]

See test (3.13, minimal, mariadb) for example.

Re-runing the test systematicaly fixes it. This is strange though.

ihatemoney/tests/budget_test.py:1407: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
ihatemoney/models.py:231: in get_transactions_to_settle_bill
    settle_plan = settle(self.balance.items()) or []
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.venv/lib/python3.13/site-packages/debts/solver.py:12: in settle
    check_balance(debiters, crediters)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

debiters = [(1, Decimal('-0.003333333333335630754845624324')), (3, Decimal('-0.003333333333333410308796374011')), (4, Decimal('0'))]
crediters = [(2, Decimal('8.336666666666666003493446624'))]

    def check_balance(debiters, crediters):
        def _sum(balance):
            return sum([abs(v) for _, v in balance])
    
        sum_debiters = _sum(debiters)
        sum_crediters = _sum(crediters)
    
        if abs(sum_crediters - sum_debiters) >= 0.01:
>           raise UnbalancedRequest(
                "Unsolvable : debiters (-{sum_debiters}) and crediters "
                "(+{sum_crediters}) are unbalanced.".format(
                    sum_crediters=sum_crediters, sum_debiters=sum_debiters
                )
            )
E           debts.solver.UnbalancedRequest: Unsolvable : debiters (-0.006666666666669041063641998335) and crediters (+8.336666666666666003493446624) are unbalanced.

[almet]

It's of course best to have a good look, but for intermittent issues like that, https://pypi.org/project/pytest-rerunfailures/ might be useful!

[zorun]

Debugging this a bit, this seems to happen in the test_settle_button test.

Here is the computed plan:

• member 3 must refund member 2 of 3.33 €
• member 1 must refund member 2 of 8.33 €

The test adds the first transaction from the plan, then computes a plan again to check if it's shorter, then adds the second transaction from the original plan, then recomputes a plan to check if it's empty.

The error is at the last step: the plan should be empty, but instead we get a crash because we feed incorrect data to the debts library. it's as if the last transaction was half-applied: member 1 correctly goes to 0 €, but member 2 incorrectly stays with a positive balance of 8.33 €.