mleku™️ @mleku - 1mo
i have been hammering away at trying to isolate the location where i'm getting some kind of bogus data being overwritten in a race - or something - and i've spent so many hours chasing this one out of all the bug types that i encounter in #golang the worst kind are scope shadowing bugs these are usually where a variable is given a name in one scope, and then inside the same scope another inner scope block declares this variable again, and then later accesses see one version and others see others i know it's not a concurrency bug because i've eliminated that by ensuring the values are copied so there's still some little sneaky bastid variable pretending to be some other variable that is kicking my arse right now i need a break lol... fucking scope shadow bugs i know i'm gonna kick myself when i finally see it because it's gonna be really obvious, and when i find it, oh man... the way it caused this error is gonna be firmly stamped into my memory, i might even print out a screenshot of the bug and hang it on my wall for a while so i don't forget how it happened and get better at learning to see it the absolute worst... when it all looks right and yet somehow variables contain things that the superficial reading of the code says it should, the worst kind of bug of all, it's the one thing that is still wrong in #golang i am pretty sure i have even declared this on the golang nuts mailing list, that scope shadowing should be an error #devstr #deardiary
https://pkg.go.dev/golang.org/x/tools/go/analysis/passes/shadow there is a tool, now to learn how to use it... i am almost certain i'm gonna find a heap of potential gotchas in this codebase
well, it found mostly typical examples of scope shadows in the form of := declarations with an error value in the return but no obvious scope shadows... oof, the pain!
finally found it the problem was something missing - where it accepts events and puts them into a heap, it wasn't putting the event serial into the record with the event no idea yet how this wasn't causing other errors but it seems to be fixed the red flag was an error saying that it couldn't find an access timestamp record that should have been there this never happens now with that change made lots of mess to clean up but the bug is fixed, now i can at last move on! nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qqsqx8h7wvasknm3u5w7n0536spmluqnq6lw4q2u0jr5larcc2kapyqn6sput
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr so i have now tested it, with my code working properly, and two things are happening that you might need to look at: - notification messages don't appear at all with no database mode on and everything coming from the relay - i think the queries are not being made correctly - messages are also not appearing, again, this seems to be connected to the previous in general, there is now a minor new bug that the notifications, even in browser cache mode, are not being fetched, except if you reload the app (alt f5/ctrl-R) i suspect there is a connection between all of them also, thanks for doing the thing with the database options... not sure i like the layout (don't see why it can't be in the database tab at the top of settings) but it's working and helps with developing relays... when you fix the message/notification queries issue it will be platinum plated epic nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpzfmhxue69uhhytndd3jkkafwv3jhvtcqyqgm3lgj0hz5yrjzqt52x00m94gpmc7l4yudhn3njkcyfazl2shnkmajw5p
until it lasts for a week on one bug, then it hurts on the bright side, i did a lot of really good and important refactoring, logging, comments... so glad to be able to move on... now i can check off more items of my todo list