core: Postgres sync corrupts blocks from 98493
When doing a fresh sync with the latest version of backend / core. Fresh node, fresh DB blocks are not processed correctly from block 98493.
Seems like some cache or array map index mismatch. Will check it out.
See error:
`I0205 11:21:58.422185 1 server.go:1147] Server._handleBlock: Received block ( 98492 / 101262 ) from Peer [ Remote Address: 34.123.41.111:17000 PeerID=1 ] I0205 11:21:58.661121 1 server.go:1147] Server._handleBlock: Received block ( 98493 / 101262 ) from Peer [ Remote Address: 34.123.41.111:17000 PeerID=1 ] panic: assignment to entry in nil map [recovered] panic: assignment to entry in nil map
goroutine 116 [running]: github.com/go-pg/pg/v10.(*Tx).RunInTransaction.func1() /root/go/pkg/mod/github.com/go-pg/pg/v10@v10.10.0/tx.go:91 +0x86 panic({0x10a30a0, 0x16fdd80}) /usr/lib/go/src/runtime/panic.go:1038 +0x215 github.com/deso-protocol/core/lib.(*Postgres).flushPosts(0xa33af3, 0xc0bac47f90, 0xc0009e1680) /deso/src/core/lib/postgres.go:1462 +0x94a github.com/deso-protocol/core/lib.(*Postgres).FlushView.func1(0x0) /deso/src/core/lib/postgres.go:1303 +0x7d github.com/go-pg/pg/v10.(*Tx).RunInTransaction(0xc0bb0334c0, {0x172c7e8, 0xc00003a290}, 0xc0b3b1d638) /root/go/pkg/mod/github.com/go-pg/pg/v10@v10.10.0/tx.go:95 +0xa5 github.com/go-pg/pg/v10.(*baseDB).RunInTransaction(0xc00003a290, {0x172c7e8, 0xc00003a290}, 0xc0b3b1d688) /root/go/pkg/mod/github.com/go-pg/pg/v10@v10.10.0/tx.go:74 +0x51 github.com/deso-protocol/core/lib.(*Postgres).FlushView(0xb1df40, 0xc000010040) /deso/src/core/lib/postgres.go:1296 +0x57 github.com/deso-protocol/core/lib.(*UtxoView).FlushToDb(0xc0009e1680) /deso/src/core/lib/block_view_flush.go:16 +0x34 /deso/src/core/lib/blockchain.go:1942 +0x1946 github.com/deso-protocol/core/lib.(*Server)._handleBlock(0xc0002103c0, 0xc0003eed80, 0xc0bcf05110) /deso/src/core/lib/server.go:1193 +0x3e5 github.com/deso-protocol/core/lib.(*Server)._handlePeerMessages(0xc0002103c0, 0xc1128a2fc0) /deso/src/core/lib/server.go:1494 +0x18d github.com/deso-protocol/core/lib.(*Server).messageHandler(0xc0002103c0) /deso/src/core/lib/server.go:1534 +0x19c created by github.com/deso-protocol/core/lib.(*Server).Start /deso/src/core/lib/server.go:1710 +0xb1`
Seems the issue is related to additional NFT royalties introduced after the hard fork. Error is related to this line https://github.com/deso-protocol/core/blob/main/lib/postgres.go#L1462
This transaction 3JuEUKubpQdqioRRtyP7JrNV5Fo1FQ1iJ9QQDpCri1C59b15asubez in block 98493 has additional NFT royalties
Might be a byte to string conversion issue. Seems like byte is expected but a string is used. Not sure. Need Go crash course
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 30 (27 by maintainers)
Hey all, just an update here.
@lazynina put out a fix in this PR:
We are now re-running a full sync from scratch to make sure there aren’t any more surprises, but feel free to give it a shot yourselves in the meantime.
I also wanted to take a moment to apologize for the pain you guys felt on this one. Across the core team, we have treated Postgres as a secondary data store, not used in consensus or our production nodes, and not yet integrated into our extremely thorough test suite.
The reason for this is that we have some fear that Postgres will not scale well as DeSo usage increases. And so, while it’s useful for apps getting off the ground, we have yet to make a go or no-go decision with regard to whether we want to offer full long-term support for it.
The above being said, given that serious apps like NFTz are now relying on it, I think we are leaning toward working around Postgres’s limitations. In particular, we have made a few breakthroughs with a new syncing mechanism we call Hypersync that, if applied to our Postgres path, should allow it to scale reasonably well.
All this to say: We’re trying really hard to support Postgres at the level that we support all core code, and we appreciate your patience with us as we work out the kinks. I know how useful it is to have a SQL interface over the DeSo data, and we’re doing everything we can to keep this a viable path for you guys long-term.
My resync just hit another issue FYI. We’re digging into it. At this point it may be faster to just bite the bullet and hook Postgres into our test suite.
I will try and do this today, which should allow us to catch all issues like this in the future.
sync complete @diamondhands0
Just an update here: Still hunting down the issue. I believe it was due to the encoding of the royalty maps, which I just fixed in this commit:
My sync runs pretty quickly, so my hope is that this works, and we can defer integrating Postgres into our test suite, which is a bigger effort than I expected.
@mvanhalen I see the issue. We need to initialize the make with a make(map[string]uint64) before we start filling it in.
@mvanhalen - thanks for flagging this. I’m out of pocket this weekend, but will investigate first thing on Monday.
Just hit the same error myself. Should be able to fix it tonight. Luckily this one shouldn’t require a resync after it’s fixed.
Yep looks like Messaging v3 does not support postgres yet
The metadata needs to be added:
https://github.com/deso-protocol/core/blob/8107b9be5883f117a676bb72b1fcf4707404461c/lib/postgres.go#L107
and then used here
https://github.com/deso-protocol/core/blob/4809196253d78a6dee8493d8b18a7e6e39c1b2c6/lib/postgres.go#L1125
and a migration added to create the required tables:
https://github.com/deso-protocol/core/tree/main/migrate
cc @AeonSw4n
k great ive just rebuild with those changes and sync was at 49k so lets see if that manages to remain ok.
Working with @tijno on this @lazynina .
Added
AdditionalNFTRoyaltiesToCoinsBasisPoints: make(map[string]uint64), AdditionalNFTRoyaltiesToCreatorsBasisPoints: make(map[string]uint64),below extra data on https://github.com/deso-protocol/core/blob/main/lib/postgres.go#L1447
It compiled and running that for a sync. Will know the result tomorrow.
@diamondhands0 @maebeam backend images have not been updated yet
Green with envy here 🤣
@diamondhands0 @lazynina as per @tijno’s comment above, if you could update the docker image that’d be awesome 👍
Fully synced now as well! nftz.zone back in sync as well. Now full focus on version 2 again.
Looks like image for backend has not yet been regenerated ?
stable and latest still 4 days old.
usually its pretty instant.
I think it’s finally fixed. I just finished syncing a Postgres node, and it made it all the way to the end. This was the final commit that was needed to fix all the issues:
I cut a new release v2.0.5 so just rebooting your nodes should get you to the end if you had the MessagingGroup issue.
Please let me know once your syncs complete!
Just synced past 98599 till 98714. Got a new error. @diamondhands0 @tijno Which is progress.
` Server._handleBlock: Encountered an error processing block <Header: < 98714, 0000000000005428375f6ee0666ae8bde2cc3 432da490d53f8588341c542b4a6, 1 >, Signer Key: BC1YLh768bVj2R3QpSiduxcvn7ipxF3L3XHsabZYtCGtsinUnNrZvNN>. Disconnecting from peer [ Remote Address: 35.232.92.5:17000 PeerID=9 ]:
Error while processing block: : ProcessBlock: Problem upserting block and transactions: InsertTransactionTx: Unimplemented txn type MESSAGING_GROUP `
Seems group messaging transactions have an issue with Postgres
Cool, just rebuild and syncing from 94500 so will let all know.
Thank you so much for the alert on this - I’ll pause my sync (~80k) in the hope we can fix this without another resync.
Confirmed on my end too. Also mentioned by kanshi on discord.