Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Another messed up event #49

Open
kaber2 opened this issue Apr 26, 2024 · 1 comment
Open

Another messed up event #49

kaber2 opened this issue Apr 26, 2024 · 1 comment

Comments

@kaber2
Copy link

kaber2 commented Apr 26, 2024

So you finally managed to add the token index to RemoveLiquidityOne. About time.

Your good fortunes seem to have ended there, the PlainPoolDeployed event still does not include the deployed pool address and is just as useless as before. Even more surprising because the Crypto factories have actually been fixed. Sigh.

But what crowns it is the TokenExchange event for the new exchange_received() method, with the input amount being 0 (well 1 I guess, because you couldn't be bothered to move the assertion to the proper place).

Seriously guys, have you ever considered actually testing the crap you unleash on the world? This stuff is not particulary hard to get right, but for years now, whenever you touch something, it gets worse.

Even with the full information the events are still largely useless on their own because they lack vital data for actually understanding what happened, such as the fees that got applied to the trade, which can't be derived from the event data, so the full trade needs to be recalculated, which in turn requires token rates that are not communicated, neither are their sources, etc. Every other exchange on the other hand manages to communicate all vital data just fine.

Bildschirmfoto vom 2024-04-26 18-53-29

Yeah yeah I know you fixed it now. Unfortunately too late, the workaround of processing all token transfers to the pool is needed now, so it really doesn't matter. This could have easily been avoided by simply testing your crap.

@kaber2
Copy link
Author

kaber2 commented Apr 26, 2024

Well actually its even worse than I thought. Because you're adding the useless _dx value to the event, but force people to chose a random value that is not zero because you were too lazy to move the assertion to the proper place, a broken event now contains essentially random data and can not easily be told apart from a non broken one.

So I guess its codehash time. MFG. I've never seen such an unbelievable mess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant