no problem, this is the first time i see this, gonna make some more resilient logic for this unusual case
Discussion
there's quite a bit of events with shit like that :/
no, it's a filter, a field in a REQ envelope
events are stringently sanitised and rejected already, this is new, filters with bech32 encoding
i have to go through the entire index search generation function and put sanitizers in
it's not unexpected, just this is literally the first time i see it right now after running this on and off in tests
yeah, i found a few cases where errors aren't being handled, my bad
yeah, i'm now currently being reminded of why the general idiom of APIs in #golang every function has a final return parameter of `error` type
in this case, i add a nil check and skip the item and log an error... there was three other cases where errors were not being handled
- first rule of #golang #fightclub - you do not fail to handle the error case first
- second rule of #golang #fightclub - you do not fail to handle the error case first
i'm seriously now going to audit the whole codebase in the near future for all methods that don't have "err error" as their last return parameter and fix this up... it might be a big change in places but that's why we have go modules, you can use my old one, with the maybe you might forget to check if it's nil as an error, and later you can revise your api calls with the "oh, sorry, you have to assign the values first and then use them because if it's nil actually your code should not proceed, and that's not obvious"