amount_residual not being computed (correctly)

[BryanSomko]

module: auditlog
version: 19.0

Steps to reproduce
created demo database with belgian accounting and demo data
install accounting and auditlog
create audit rule for account.move (this is only rule that is active)

Create bank journal:

create random vendor bill for customer with trusted bank account:

press pay and select created journal

Go to Journal items and search for the lines with the Memo from the pay wizard.

• ...

Current behavior
the created account.move.line in screenshot did not get the correct 'amount_residual' calculated
Expected behavior
if you deactivate the account.move audit rule again, and undo the payment and create the payment again. The amount_residual wil be computed correctly

[skanndar]

We hit the same bug in production (payments no longer offered as outstanding credits on their invoices) and tracked it down.

With a full-log rule on account.move, write_full() performs its old/new-values reads inside the ThrowAwayCache context manager while move lines touched earlier in the transaction still have pending recomputations of their stored computed fields (amount_residual, amount_residual_currency, reconciled). Tracing the transaction state around those blocks shows that the context manager restores tocompute intact on exit, but after that swap/read/restore cycle the pending recomputations are consumed by the subsequent write + flush without ever being persisted: they leave tocompute, never show up in field_dirty, and the database columns stay NULL. The outstanding-credits widget domain (_compute_payments_widget_to_reconcile_info) ends in '|', ('amount_residual', '!=', 0.0), ('amount_residual_currency', '!=', 0.0), and with both columns NULL neither leg matches — so the payment never shows up.

Reproduced on a virgin database with only account (demo data) + auditlog (current 19.0): full-log rule on account.move → post a customer invoice → register a payment → the payment's liquidity line is born with NULL amount_residual/reconciled. With a Fast log rule the very same flow is fine.

Proposed fix with a regression test in #3718: flush everything still pending before setting the cache aside, in ThrowAwayCache.__enter__. The test fails on current 19.0 and passes with the fix; the whole auditlog + test_auditlog suite is green.

Workaround meanwhile: switch the rule to Fast log. Note a plain write() on the rule is not enough to repatch the model — use Set to draft → change the log type → Confirm. Lines already corrupted need their stored computed fields recomputed.