Closed dominictarr closed 8 years ago
ok this works, i'm testing it on v6! Ill down grade to v5 in a bit and test
@wanderer let me know once youre replicating dust's messsages again
@pfraze it looks like I can now, but I still have quite a few missing messages... i'm guessing they are from other feeds that broke
@wanderer use this script https://github.com/ssbc/examples/blob/master/good-hash.js to find feeds that have the wrong hash. it doesn't currently tell you whether it's saved as the wrong hash, that would be a small change though, which I would make right now if I wasn't right aboit to have breakfast
@wanderer okay I updated the script to tell you only what feeds have the wrong hashes. Since this stops replication, it will always be the last hash you have on that feed, and you are sure to have hashes that already have these problematic hashes, we just need to check if you have messages that have been saved with the wrong hash. pull the latest version of that script, and lets see if there are are more feeds you have that are broken.
ok @dominictarr here is the result of stderr & stdout of the above script out.txt
cool, so if you run @pfraze 's delete script on those feed/seq pairs you should be good again. lets see if this works, then we'll merge this PR.
it seems like @pfraze scirpt is picky about the order
node delete-msg.js "%6d3BkD5r2+yeI3O/kkcmgS3nQajAPV7cKeJ6pKQd3lo=.sha256"
error, must be last message by author
last msg was sequence number 170
this msg is sequence number 4
so i need to delete the last message and work backward to the corrupted message?
Yeah, it gets a little bit harder to delete messages that arent the last. I'll have to update the script.
@dominictarr one thing that's a bit of a pain is that the local timestamp (receive time) is only used as a key in certain indexes, so it's hard to lookup any message that is indexed by local time. And, actually, there are two local timestamps used, because mynosql generates its own, and then ssb uses another.
you shouldn't have any messages stored with the wrong hash except the last one, because once the corrupt message goes in, no more messages after that will be valid.
you should only need to delete messagse from these feeds
{
"@hGd3sjghbrkVaFEMUrXV11m2oyKLfLqJQcadvapH02w=.ed25519": 45,
"@lzMHSo63Do77Fg4qdDrcIk6yJ+HWQs6YH+fD217S6+s=.ed25519": 463,
"@6ilZq3kN0F+dXFHAPjAwMm87JEb/VdB+LC9eIMW3sa0=.ed25519": 290,
"@uikkwUQU4dcd/ZrHU7JstnkTgncxQB2A8PDLHV9wDAs=.ed25519": 649,
"@hxGxqPrplLjRG2vtjQL87abX4QKqeLgCwQpS730nNwE=.ed25519": 3332,
"@f/6sQ6d2CMxRUhLpspgGIulDxDCwYD7DzFzPNr7u5AU=.ed25519": 730,
"@p13zSAiOpguI9nsawkGijsnMfWmFd5rlUNpzekEE+vI=.ed25519": 1235,
"@iL6NzQoOLFP18pCpprkbY80DMtiG4JFFtVSVUaoGsOQ=.ed25519": 864
}
hang on, I'll update the script to output the message ids.
okay I added a script to that repo: bad-hash.js which says these are the hashes you need to delete.
%j3S9DwP0khXZa9oBDx8ZDD8VfyItati1AInjTcbM70g=.sha256
%xMsWfeZd+WNa+XcCODfnTQ9oXp87xf2EfNDQzVilxW4=.sha256
%aBlRZlZRN1sakyLhJ0+w6MXFQoVmqf8vaa7zxPwxXSw=.sha256
%/3vn4elqLCDTXf52Inb/dBjdHva1vDI5+v3njOmHweY=.sha256
%jPMw5cHTbzrVPhnQ2Yfx9Yul8RAvD24lL7AkDg+OZwk=.sha256
%cfBUiUb9hsvLLw6ViczLUmyQggQ+NKFdb1g0/6P2WXI=.sha256
%Ccqnvt/fZEXTziggz45bPqBVGewOQLPWqtfJGp9cy9k=.sha256
%W9mq+w6LT1vdJZfu2NRpHc8zcQFSUKZLI9L9rsp6IGg=.sha256
then you should be good again. dust's hash isn't there because you already deleted it before ran that script, right?
Ok I have deleted all bad messages
also After deleting and re syncing no new bad messages where created. So it looks like everything is in order! thanks @dominictarr & @pfraze :)
Good deal.
@dominictarr I suggest we actually merge this, to make sure nobody else gets hit, and then work on the permanent fix
cool, merging.
merged into 5.0.1
This will fix the fork that @wanderer found. https://github.com/ssbc/patchwork/issues/343#issuecomment-201381664
Turns out there are lots of messages that hash wrong, but we only recently discovered this, because the default behavior only changed in node@6, which so far only dust has used, (actually, node@6 isn't even an official version yet!)
This change will make it hash consistently in node@6, as it did in node@<6
I think this should be a discussion PR for now, if @wanderer can downgrade to node@5, and we can figure out how to upgrade to a new hash/encoding that doesn't have this unfortunate bug.