Disbursing rewards

Support
21

Can't the approve/increaseAllowance call happen inside of disburseReward?

I'm assuming supplying uint256(-1) basically gives the contract virtually infinite allowance. Wondering if I can use BigNumber.toTwos for this in the test script.

It does make sense that the contract can't approve itself though. :joy:

22

Yes, this method works. Thanks for your assistance!

Only caveat is that a weird "transaction should have reverted" error is thrown if all the tests are run (without an expect statement). Running them one at a time doesn't trigger it.

23

No, you can not.

uint256(-1) is equal to 2**256-1

Not sure why this comes, maybe you can share more details if you want.

24 
  BanzanToken
    √ Should have symbol ZAN (for now) (1159ms)
    √ Should not be able to attach to existing contract deployments for BanzanToken

  RewardClaim
    √ Should not deploy RewardClaim if BanzanToken has no supply (169ms)
(node:50460) UnhandledPromiseRejectionWarning: AssertionError: Expected transaction to be reverted
(Use `node --trace-warnings ...` to show where the warning was created)
(node:50460) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 29)
(node:50460) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
    √ Should deploy RewardClaim if BanzanToken has supply (1210ms)
DEBUG: claim succeeded!
disburseReward success.
    √ Should disburse rewards (1262ms)


  5 passing (4s)

I used BigNumber.from(-1).toTwos(256) in the TS script.

25

Not sure for this warning, it seems like there is a promise you do not resolve correctly, I am not familiar with the promise, I always use async()/ await().

26

Well it turns out it was the promise executed at the end of one of the test cases that always threw when it was executed in sequence with the next one. Both tests were actually redundant so I removed them.

The reason for passing a Promise<T> around directly is because the Chai-Waffle expect({transaction-promise}).to{.not}.be.reverted requires it.

1 Like