To be discussed in our meeting:
arb grant doc model accepts bad input, for at least fundingAddress
{"authorizedSignerAddress":"0xc7a8de05264442a318189f2bd160d2830902c8cd","disbursementContractAddress":"0x8C2b8595eA1b627427EFE4f29A64b145DF439d16","fundingAddress":"arb1:0x8C2b8595eA1b627427EFE4f29A64b145DF439d16","fundingType":["EOA"],"grantSize":750000,"grantSummary":"The grant will largely be focused on expanding liquidity of LRTs and stETH across Arbitrum. ","granteeName":"Lido","matchingGrantSize":750000,"metricsDashboardLink":"https://dune.com/pipistrella/lido-arbitrum-ltipp","numberOfPhases":1,"phaseDuration":1,"startDate":"2024-06-13T18:13:48.589Z"}
We flip-flopped a couple of times to establish the right pattern for input validation so, depending on what the approach is here: it could be that the reducer doesn't throw an exception while it definitely should, in this case. Or it could be that it throws an exception but the operation was still added to the document history with the error logged as part of the output. But in this case, the right behaviour would be that the exception is thrown at some point before the operation is created so it never gets added to the document history. And then of course it should inform the calling code of the rejection.
To be discussed in our meeting: arb grant doc model accepts bad input, for at least fundingAddress
{"authorizedSignerAddress":"0xc7a8de05264442a318189f2bd160d2830902c8cd","disbursementContractAddress":"0x8C2b8595eA1b627427EFE4f29A64b145DF439d16","fundingAddress":"arb1:0x8C2b8595eA1b627427EFE4f29A64b145DF439d16","fundingType":["EOA"],"grantSize":750000,"grantSummary":"The grant will largely be focused on expanding liquidity of LRTs and stETH across Arbitrum. ","granteeName":"Lido","matchingGrantSize":750000,"metricsDashboardLink":"https://dune.com/pipistrella/lido-arbitrum-ltipp","numberOfPhases":1,"phaseDuration":1,"startDate":"2024-06-13T18:13:48.589Z"}