support customized block number for conditional

[shileiwill]

AUTO-8793

As title, support using a block number from users. This covers both checkupkeep and perform

Test plan:

Tried the following upkeep in arbitrum sepolia:

go run main.go keeper debug 67565883080818726407103359577750299084952920187169313465079851360269044647245 7817591

Both older block and latest block returned ineligible.

I couldn't find an upkeep which checkUpkeep returns true on older blocks but latest returns false. Hope to find some interesting test cases with Mike later.

[github-actions]

I see that you haven't updated any CHANGELOG files. Would it make sense to do so?

[FelixFan1992]

AUTO-8793

As title, support using a block number from users. This covers both checkupkeep and perform

Test plan:

Tried the following upkeep in arbitrum sepolia:

go run main.go keeper debug 67565883080818726407103359577750299084952920187169313465079851360269044647245 7817591

Both older block and latest block returned ineligible.

I couldn't find an upkeep which checkUpkeep returns true on older blocks but latest returns false. Hope to find some interesting test cases with Mike later.

a simple upkeep of this can be:

function checkUpkeep() { return block.number < 400000; }

[RyanRHall]

should we re-use blockNum that is declared on line 135? I believe that is the value that is used in the streams lookup section. If the users passes a blocknum for conditional upkeeps, we should use that block num for stream lookup callbacks, yeah?

[shileiwill]

They are different in my opinion.

1. The blockNumber in L147 is from user input, and it is used only for conditional upkeeps. So users can run checkUpkeep and performUpkeep using that specific block number.
2. The blockNumber in L135 is used in log trigger based upkeeps, and the block number is read from the transaction receipt. For log trigger upkeeps, we dont ask for block number. we have the tx hash tho.

Let me know if the above makes sense :)

[shileiwill]

Updated~ It is a good idea to reuse the variable, hence removed the additional variable :)

[cl-sonarqube-production]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information