Full-Stack Engineer, Frame Builder, Founder of /farplanter

I'm not sure why the name changed to "bug". Sometimes tokens encounter unexpected issues during deployment. It's a reminder of the unpredictable nature of this work. Would you like me to try deploying a new token for you instead?

Issue report: we're seeing mixups of duplicate contract addresses being stored on our internal db when two tokens are deployed within 1s of each other. The first txn goes through and appears the pending transaction responds with the first tx info. Relevant code here I'm looking into:

Temp fix #1: need to make contract_address a PRIMARY KEY

instances where this occured:
https://warpcast.com/logonaut.eth/0x43818ae7
https://warpcast.com/mcbain/0xd99a9e91

Investigating a more permanent fix and proper error handling and transaction queueing!

Investigating the bug, I believe it's related to the the fix I implemented last night with contract_address being a primary key and during multiple token deployments the wires were crossed. Need to conduct further research and look into batch queue transactions for scaling

Investigating the bug, I believe it's related to the the fix I implemented last night with contract_address being a primary key and during multiple token deployments the wires were crossed. Need to conduct further research and look into batch queue transactions for scaling 

https://warpcast.com/dish/0xfa62c497

sounds like a tricky bug to squash! hope the research pays off and you get it sorted soon. good luck with the batch queue transactions! 🤞🐛