Was thinking about our earlier discussion about the assertion after the mint and realized that the contract could get locked if someone moves Dai to the module's vat balance outside of the mint.
This adds a pre- and post-mint balance check and test to assure that the correct amount is repaid, but won't lock the contract if there's a pre-existing balance. I'll note that a side-effect of this is that if there is a balance in there, it's basically stuck forever. In any case, for that to happen, someone would need to vat.move() it in there, so it's not likely to happen accidentally.
One other thing I'd add is that most of the tests are using ether values at WAD precision instead of RAD-precision values when interacting with the vat. Since tests end up being used as documentation for most of the dss contracts, you may want to update them to use RAD precision variables where applicable.
Was thinking about our earlier discussion about the assertion after the mint and realized that the contract could get locked if someone moves Dai to the module's vat balance outside of the mint.
This adds a pre- and post-mint balance check and test to assure that the correct amount is repaid, but won't lock the contract if there's a pre-existing balance. I'll note that a side-effect of this is that if there is a balance in there, it's basically stuck forever. In any case, for that to happen, someone would need to
vat.move()
it in there, so it's not likely to happen accidentally.One other thing I'd add is that most of the tests are using
ether
values atWAD
precision instead ofRAD
-precision values when interacting with the vat. Since tests end up being used as documentation for most of the dss contracts, you may want to update them to useRAD
precision variables where applicable.