Open mikeshultz opened 5 years ago
~Resolved by #2766~
Actually, this issue is more for the DApp side of the equation, right @mikeshultz?
Yes, this issue was specifically created for the dapp. I thought you were a label guy, @micahalcorn!
Yes, thanks, I was too quick and eager to close things. 😬
This may be the source of errors we see in the listener where some ProxyCreation events are fired with an address of zero. Listener logs:
[31;22m[ERROR] [39;1mevent-listener[0m: Error: Invalid proxy address in ProxyCreation event: 0x0000000000000000000000000000000000000000 at ProxyEventHandler.process (/app/infra/discovery/src/listener/handler_proxy.js:49:13) at withRetrys (/app/infra/discovery/src/listener/handler.js:90:30) at withRetrys (/app/infra/discovery/src/listener/utils.js:78:20) at handleEvent (/app/infra/discovery/src/listener/handler.js:89:11) at process._tickCallback (internal/process/next_tick.js:68:7) 'will retry in 0.108 seconds, retry count 0'
This is not causing an issue for the listener. After some retries the processing of the event is skipped. As such, not worth raising the priority of this issue.
The dapp is rapid-firing some requests way too quickly.
These two transactions were sent to the relayer within a 1/10th of a second of eachother and ended up landed on the same block! Same inputs, user, and proxy, so this wasn't even multiple updates by the user but the dapp firing multiple requests.
0x26647e6d590d72ebd7748963d92c0eadc2d84b43a529d54660e90e4e47c03a36
(good)0xeb32832102007d2eacfe345e68f2ed9413141f15e02ba4179242b0c56b45a430
(revert)The dapp should probably show some level of restraint here.