indexes: Stop using node internal types #25494

ryanofsky · 2022-06-28T20:14:51Z

Start transitioning index code away from using internal node types like CBlockIndex and CChain so index code is less coupled to node code and index code will later be able to stop locking cs_main and sync without having to deal with validationinterface race conditions, and so new indexes are easier to write and can run as plugins or separate processes.

This PR contains the first 7 commits from #24230 (comment) which have been split off for easier review. Previous review comments can be found in #24230

DrahtBot · 2022-06-29T00:33:23Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#25623 ([kernel 3e/n] Decouple CDBWrapper and CBlockTreeDB from ArgsManager by dongcarl)
#25297 (WIP, wallet: speedup transactions sync, rescan and load not flushing to db constantly by furszy)
#25222 (refactor: Pass reference to LookUpStats by MarcoFalke)
#24150 (refactor: move index class members from protected to private by jonatack)
#19888 (rpc, test: Improve getblockstats for unspendables by fjahr)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

maflcko · 2022-06-29T06:25:49Z

src/node/chain.cpp

+        info.prev_hash = index->pprev ? index->pprev->phashBlock : nullptr;
+        info.height = index->nHeight;
+        LOCK(::cs_main);
+        info.file_number = index->nFile;


It seems that this will only copy/alias the internal memory to a different type. I wonder if this is actually useful, because it disables lock annotations for the memory where they may actually still be needed? Also, I wonder how useful an interface is that returns a data structure that points into memory that is owned by a different process (I am assuming each blockindex runs in a different multiprocess)

re: #25494 (comment)

In commit "interfaces, refactor: Add more block information to block connected notifications" (0a93a16)

It seems that this will only copy/alias the internal memory to a different type. I wonder if this is actually useful, because it disables lock annotations for the memory where they may actually still be needed?

I don't think there's actually a concern here, and this is what current code already does. cs_main is locked while reading nFile and nDataPos values, but not when ReadBlockFromDisk is called. Values are copied first and then used.

Also, I wonder how useful an interface is that returns a data structure that points into memory that is owned by a different process (I am assuming each blockindex runs in a different multiprocess)

The change in this commit is to replace individual block & height parameters with a BlockInfo struct parameter that can hold more information about the block:

- virtual void blockConnected(const CBlock& block, int height) {} - virtual void blockDisconnected(const CBlock& block, int height) {} + virtual void blockConnected(const BlockInfo& block) {} + virtual void blockDisconnected(const BlockInfo& block) {}

The point of using the struct is to make code more readable and avoid the need to update blockConnected/blockDisconnected declarations when more block information is needed.

Semantically there's no difference between passing a const uint256& hash parameter vs adding a const uint256& hash; struct member, or passing an int file_number parameter vs. adding an int file_number; struct member. All the copy and reference and lifetime concerns are the same.

It is true that because referencing memory in other processes is not possible, multiprocess code will create local copies of values when references are passed, and the local copies may have shorter lifetimes than original references. But this is true wherever references and pointers are used in src/interface/ classes, so not a new thing.

fjahr · 2022-07-02T23:15:44Z

Linter warns of a circular dependency

A new circular dependency in the form of "index/base -> node/context -> net_processing -> index/blockfilterindex -> index/base" appears to have been introduced.

ryanofsky

re: #25494 (comment)

Linter warns of a circular dependency

Thanks! Should be fixed

Updated 3c82fa5 -> ddbbdcf (pr/ind.1 -> pr/ind.2, compare) to fix lint-circular-dependencies.py error

ryanofsky · 2022-07-05T16:52:54Z

src/node/chain.cpp

+        info.prev_hash = index->pprev ? index->pprev->phashBlock : nullptr;
+        info.height = index->nHeight;
+        LOCK(::cs_main);
+        info.file_number = index->nFile;


re: #25494 (comment)

In commit "interfaces, refactor: Add more block information to block connected notifications" (0a93a16)

It seems that this will only copy/alias the internal memory to a different type. I wonder if this is actually useful, because it disables lock annotations for the memory where they may actually still be needed?

I don't think there's actually a concern here, and this is what current code already does. cs_main is locked while reading nFile and nDataPos values, but not when ReadBlockFromDisk is called. Values are copied first and then used.

Also, I wonder how useful an interface is that returns a data structure that points into memory that is owned by a different process (I am assuming each blockindex runs in a different multiprocess)

The change in this commit is to replace individual block & height parameters with a BlockInfo struct parameter that can hold more information about the block:

- virtual void blockConnected(const CBlock& block, int height) {} - virtual void blockDisconnected(const CBlock& block, int height) {} + virtual void blockConnected(const BlockInfo& block) {} + virtual void blockDisconnected(const BlockInfo& block) {}

The point of using the struct is to make code more readable and avoid the need to update blockConnected/blockDisconnected declarations when more block information is needed.

Semantically there's no difference between passing a const uint256& hash parameter vs adding a const uint256& hash; struct member, or passing an int file_number parameter vs. adding an int file_number; struct member. All the copy and reference and lifetime concerns are the same.

It is true that because referencing memory in other processes is not possible, multiprocess code will create local copies of values when references are passed, and the local copies may have shorter lifetimes than original references. But this is true wherever references and pointers are used in src/interface/ classes, so not a new thing.

mzumsande

ACK ddbbdcf

I reviewed these commits multiple times as part of #24230, and think they are good.
I also did some manual testing for this PR on regtest and signet and didn't see any differences in behavior.

While it's a bit unfortunate that this introduces a circular dependency, this is transitory and will get removed with the last commits of #24230 after all internal uses of CChainState are removed.

nit: clang-format suggests a few minor changes (spacing) over these commits

fjahr

tACK ddbbdcf

Reviewed code and ran it, syncing txindex from intermittently synced state to fully synced and fully synced coinstatsindex from scratch.

fjahr · 2022-07-08T22:24:11Z

src/wallet/test/fuzz/notifications.cpp

-                a.wallet->blockDisconnected(block, chain.size() - 1);
-                b.wallet->blockDisconnected(block, chain.size() - 1);
+                const uint256& hash = block.GetHash();
+                const uint256& prev_hash = chain.size() >= 2 ? std::get<1>(chain[chain.size() - 2]).GetHash() : uint256();


nit: I think this line could be made a little easier to parse but since it's in fuzzing it's not so important

re: #25494 (comment)

nit: I think this line could be made a little easier to parse but since it's in fuzzing it's not so important

Simplified

fjahr · 2022-07-09T19:21:50Z

src/interfaces/chain.h

+    int file_number = -1;
+    unsigned data_pos = 0;
+    const CBlock* data = nullptr;
+    const CBlockUndo* undo_data = nullptr;


note for other reviewers: in this PR this is unused but will be used in follow-ups, see #24230

maflcko

Happy to merge as-is. Let me know what you think.

review ACK ddbbdcf 🐯

Show signature

Signature:

src/wallet/test/fuzz/notifications.cpp

src/interfaces/chain.h

src/wallet/wallet.cpp

src/index/coinstatsindex.cpp

src/Makefile.am

maflcko · 2022-07-13T15:32:37Z

src/index/blockfilterindex.cpp

            return false;
        }

-        uint256 expected_block_hash = pindex->pprev->GetBlockHash();
+        uint256 expected_block_hash = *block.prev_hash;


88cad3c: I wonder where UB should be avoided with asserts and where not

re: #25494 (comment)

88cad3c: I wonder where UB should be avoided with asserts and where not

I think it's reasonable to add Asserts all these places or add a const uint256& PrevHash() helper method which asserts, if the Assert is too verbose. Just to be clear, there shouldn't be any UB presently here due to the block.height > 0 check above. The Assert is just an extra check against possible future UB that could occur if a bug is introduced somewhere else in the code.

src/index/blockfilterindex.cpp

src/index/coinstatsindex.cpp

maflcko · 2022-07-13T15:50:52Z

src/index/base.cpp

-
-bool BaseIndex::CommitInternal(CDBBatch& batch)
-{
-    LOCK(cs_main);
    // Don't commit anything if we haven't indexed any block yet
    // (this could happen if init is interrupted).
    if (m_best_block_index == nullptr) {
        return false;


ddbbdcf: This changes behavior: Previously there was a call to error(), now there is none?

re: #25494 (comment)

ddbbdcf: This changes behavior: Previously there was a call to error(), now there is none?

Good catch. The error print was lost because of a bad rebase. The m_best_block_index == nullptr check was added in #24117 after this was written. Fixed now

ryanofsky · 2022-07-13T19:31:50Z

Happy to merge as-is. Let me know what you think.

Thanks for review Marco. I definitely want to make some improvements based on your comments, so better not to merge for now

maflcko · 2022-07-14T06:41:28Z

src/node/chain.cpp

@@ -0,0 +1,23 @@
+// Copyright (c) 2022 The Bitcoin Core developers


Maybe add this new file to iwyu?

re: #25494 (comment)

Maybe add this new file to iwyu?

Thanks, added

https://cirrus-ci.com/task/4504627910541312?logs=ci#L6998

Looks like an iwyu bug, so maybe undo for now?

re: #25494 (comment)

https://cirrus-ci.com/task/4504627910541312?logs=ci#L6998

Looks like an iwyu bug, so maybe undo for now?

I'm not actually sure what the bug is but I added some missing includes and undid change that adds the file to IWYU for now. The larger PR #24230 this was part of adds more to this file so there is a chance to enable IWYU again later

ryanofsky

Updated ddbbdcf -> fb245ec (pr/ind.2 -> pr/ind.3, compare) with suggested changes like moving the new file from node/ to kernel/
Updated fb245ec -> f678151 (pr/ind.3 -> pr/ind.4, compare) to fix lint error https://cirrus-ci.com/task/6068993915092992

src/interfaces/chain.h

ryanofsky · 2022-07-14T19:28:35Z

src/node/chain.cpp

@@ -0,0 +1,23 @@
+// Copyright (c) 2022 The Bitcoin Core developers


re: #25494 (comment)

Maybe add this new file to iwyu?

Thanks, added

src/index/coinstatsindex.cpp

ryanofsky · 2022-07-14T19:28:58Z

src/init.cpp

            return false;
        }
    }

    for (const auto& filter_type : g_enabled_filter_types) {
-        InitBlockFilterIndex(filter_type, cache_sizes.filter_index, false, fReindex);
-        if (!GetBlockFilterIndex(filter_type)->Start(chainman.ActiveChainstate())) {
+        InitBlockFilterIndex([&]{ return interfaces::MakeChain(node); }, filter_type, cache_sizes.filter_index, false, fReindex);


re: #25494 (comment)

2f8a530: Wrapping this into a function to avoid moving a pointer seems overkill?

Reason this is using a std::function is I was looking for a simple way to allow the Init*Index functions to stay where they are in src/index/ without referencing the NodeContext struct. Maybe this isn't a critical goal though, or there is a better way of achieving it. Since I want to extend #10102 to run indexes separately I will have to revisit this code anyway later, so happy to go with whatever would be suggested now if this is not good.

src/Makefile.am

src/wallet/test/fuzz/notifications.cpp

ryanofsky · 2022-07-14T19:31:50Z

src/wallet/test/fuzz/notifications.cpp

-                a.wallet->blockDisconnected(block, chain.size() - 1);
-                b.wallet->blockDisconnected(block, chain.size() - 1);
+                const uint256& hash = block.GetHash();
+                const uint256& prev_hash = chain.size() >= 2 ? std::get<1>(chain[chain.size() - 2]).GetHash() : uint256();


re: #25494 (comment)

nit: I think this line could be made a little easier to parse but since it's in fuzzing it's not so important

Simplified

src/wallet/wallet.cpp

src/index/blockfilterindex.cpp

maflcko

f678151 📭

Show signature

Signature:

maflcko · 2022-07-15T07:39:14Z

src/index/base.cpp

-    if (m_best_block_index == nullptr) {
-        return false;
+    bool ok = m_best_block_index != nullptr;
+    if (ok) {


This is still wrong?

Previously the call order was CoinStatsIndex::CustomCommit , then BaseIndex::CommitInternal (which may be skipped).

Now, everything is skipped?

re: #25494 F438 (comment)

In commit "indexes, refactor: Remove CChainState use in index CommitInternal method" (f678151)

This is still wrong?

Previously the call order was CoinStatsIndex::CustomCommit , then BaseIndex::CommitInternal (which may be skipped).

Now, everything is skipped?

You are referring to the m_best_block_index == nullptr case? If so then yes the whole commit is skipped now when previously only half of the commit was skipped (custom part was not skipped, base part was skipped).

I didn't notice yesterday that only the base half of the commit was skipped, but it's definitely better to skip the whole commit. This m_block_index == nullptr case was only added very recently in 0243907 as part of an attempt to avoid index corruption if state was flushed during startup that would happen because GetLocator can return null on startup. It was an imperfect attempt and according to comments in #24117 (comment), corruption continued to happen after that PR. It's possible this commit might inadvertently fix this by skipping the whole commit instead of half of it, but it's not clear. In any case, it should be better behavior and it makes more sense to skip the whole commit.

I think that skipping the error message in the m_block_index == nullptr case would have actually been ok: Right now, everytime one starts to sync a new index with an existing chain, this would appear once in the error log, even though it is expected and not actually an error. But possibly this is fixed anyway by a later commit from #24230 rewriting the init logic anyway into not attempting to call commit before actually doing some indexing?

I agree that skipping the entire thing custom+base commit makes more sense, but I can't see how this could possibly avoid additional cases of corruption or be the cause of #24117 (comment), since the custom code in both coinstatsindex and blockfilterindex doesn't make use of m_block_index and just prepares custom data in the batch without committing.

ryanofsky

Updated f678151 -> 8bc1602 (pr/ind.4 -> pr/ind.5, compare) updating commit message 8bc1602 to describe some changed behavior and no longer enabling IWYU for now in the new file

ryanofsky · 2022-07-15T11:55:34Z

src/index/base.cpp

-    if (m_best_block_index == nullptr) {
-        return false;
+    bool ok = m_best_block_index != nullptr;
+    if (ok) {


re: #25494 (comment)

In commit "indexes, refactor: Remove CChainState use in index CommitInternal method" (f678151)

This is still wrong?

Previously the call order was CoinStatsIndex::CustomCommit , then BaseIndex::CommitInternal (which may be skipped).

Now, everything is skipped?

You are referring to the m_best_block_index == nullptr case? If so then yes the whole commit is skipped now when previously only half of the commit was skipped (custom part was not skipped, base part was skipped).

I didn't notice yesterday that only the base half of the commit was skipped, but it's definitely better to skip the whole commit. This m_block_index == nullptr case was only added very recently in 0243907 as part of an attempt to avoid index corruption if state was flushed during startup that would happen because GetLocator can return null on startup. It was an imperfect attempt and according to comments in #24117 (comment), corruption continued to happen after that PR. It's possible this commit might inadvertently fix this by skipping the whole commit instead of half of it, but it's not clear. In any case, it should be better behavior and it makes more sense to skip the whole commit.

maflcko

ACK 8bc1602 though did not review the last commit 🗡

Show signature

Signature:

ryanofsky · 2022-07-18T14:20:32Z

@fjahr & @mzumsande could you reack? I think only change since previous reviews has been expanding the m_block_index == nullptr case in CommitInternal to keep logging an error and avoid committing anything

…otifications Add new interfaces::BlockInfo struct to be able to pass extra block information (file and undo information) to indexes which they are updated to use high level interfaces::Chain notifications. This commit does not change behavior in any way.

…to indexes Passing abstract Chain interface will let indexes run in separate processes. This commit does not change behavior in any way.

…ne function This commit does not change behavior in any way.

Replace overriden index Init() methods that use the best block CBlockIndex* pointer with pure CustomInit() callbacks that are passed the block hash and height. This gets rid of more CBlockIndex* pointer uses so indexes can work outside the bitcoin-node process. It also simplifies the initialization call sequence so index implementations are not responsible for initializing the base class. There is a slight change in behavior here since now the best block pointer is loaded and checked before the custom index init functions are called instead of while they are called.

Replace WriteBlock method with CustomAppend and pass BlockInfo struct instead of CBlockIndex* pointer This commit does not change behavior in any way.

Replace Rewind method with CustomRewind and pass block hashes and heights instead of CBlockIndex* pointers This commit does not change behavior in any way.

Replace CommitInternal method with CustomCommit and use interfaces::Chain instead of CChainState to generate block locator. This commit does not change behavior in any way, except in the (m_best_block_index == nullptr) case, which was added recently in bitcoin#24117 as part of an ongoing attempt to prevent index corruption if bitcoind is interrupted during startup. New behavior in that case should be slightly better than the old behavior (skipping the entire custom+base commit now vs only skipping the base commit previously) and this might avoid more cases of corruption.

ryanofsky · 2022-07-18T19:06:26Z

Rebased 8bc1602 -> 7878f97 (pr/ind.5 -> pr/ind.6, compare) due to conflicts with #23997 and #25487

maflcko · 2022-07-19T08:27:42Z

ACK 7878f97 though did not review the last commit 🤼

Show signature

Signature:

mzumsande · 2022-07-19T18:01:30Z

Code Review ACK 7878f97

ryanofsky · 2023-05-18T18:01:15Z

src/index/base.cpp

+    if (!Init()) return false;
+
+    const CBlockIndex* index = m_best_block_index.load();
+    if (!CustomInit(index ? std::make_optional(interfaces::BlockKey{index->GetBlockHash(), index->nHeight}) : std::nullopt)) {


In commit "indexes, refactor: Remove CBlockIndex* uses in index Init methods" (bef4e40)

Calling the CustomInit() function after the Init() function here seems to cause a race condition, noticed by @furszy and described in #27607 (comment). The problem is that Init() can set m_synced to true, which enables BlockConnected callbacks. But if BlockConnected callback runs before CustomInit finishes the index may still be only partially loaded, and the CustomAppend call in BlockConnected could fail

…it' prior setting 'synced' flag 3126454 index: prevent race by calling 'CustomInit' prior setting 'synced' flag (furszy) Pull request description: Decoupled from #27607. Fixed a potential race condition in master (not possible so far) that could become an actual issue soon. Where the index's `CustomAppend` method could be called (from `BlockConnected`) before its `CustomInit` method, causing the index to try to update itself before it is initialized. This could happen because we set the index `m_synced` flag (which enables `BlockConnected` events) before calling to the child class init function (`CustomInit`). So, for example, the block filter index could process a block before initialize the next filter position field and end up overwriting the first stored filter. This race was introduced in bitcoin/bitcoin@bef4e40 from bitcoin/bitcoin#25494. ACKs for top commit: achow101: ACK 3126454 mzumsande: Code review ACK 3126454 TheCharlatan: Nice, ACK 3126454 Tree-SHA512: 7a53fed1d2035cb4c1f331d6ee9f92d499b6cbb618ea534c6440f5a45ff9b3ac4dcff5fb4b88937f45a0be249e3a9c6dc6c3ac77180f12ae25fc56856ba39735

…r setting 'synced' flag 3126454 index: prevent race by calling 'CustomInit' prior setting 'synced' flag (furszy) Pull request description: Decoupled from bitcoin#27607. Fixed a potential race condition in master (not possible so far) that could become an actual issue soon. Where the index's `CustomAppend` method could be called (from `BlockConnected`) before its `CustomInit` method, causing the index to try to update itself before it is initialized. This could happen because we set the index `m_synced` flag (which enables `BlockConnected` events) before calling to the child class init function (`CustomInit`). So, for example, the block filter index could process a block before initialize the next filter position field and end up overwriting the first stored filter. This race was introduced in bitcoin@bef4e40 from bitcoin#25494. ACKs for top commit: achow101: ACK 3126454 mzumsande: Code review ACK 3126454 TheCharlatan: Nice, ACK 3126454 Tree-SHA512: 7a53fed1d2035cb4c1f331d6ee9f92d499b6cbb618ea534c6440f5a45ff9b3ac4dcff5fb4b88937f45a0be249e3a9c6dc6c3ac77180f12ae25fc56856ba39735

f65b0f6 index: Move last_locator_write_time and logging to end of threadsync loop (Fabian Jahr) Pull request description: In the index sync thread, when initializing an index for the first time, stop callng BaseIndex::Commit when m_best_block_index is null, to avoid a spurious "failed to commit" error from that function. This error started happening in commit 7878f97 from #25494 and was reported by pstratem in #26903 with an alternate fix. ACKs for top commit: achow101: ACK f65b0f6 ryanofsky: Code review ACK f65b0f6. Just moved log "Syncing" log line since last commit to avoid having to call now() twice. furszy: ACK f65b0f6 TheCharlatan: ACK f65b0f6 Tree-SHA512: afa8f05786318d36346d167ff53ea0b3bc8abdb0ad04465d199dc3eb91e9f837369e24fcb7e24b5757b02d698ec504e61da6ac365eaf006c874fc07a424a7e20

ryanofsky mentioned this pull request Jun 28, 2022

indexes: Stop using node internal types and locking cs_main, improve sync logic #24230

Draft

DrahtBot added the Refactoring label Jun 28, 2022

maflcko reviewed Jun 29, 2022

View reviewed changes

DrahtBot mentioned this pull request Jun 29, 2022

rpc, test: Improve getblockstats for unspendables #19888

Merged

maflcko removed the Refactoring label Jul 1, 2022

DrahtBot added the UTXO Db and Indexes label Jul 1, 2022

Onyeali approved these changes Jul 3, 2022

View reviewed changes

ryanofsky force-pushed the pr/ind branch from 3c82fa5 to ddbbdcf Compare July 5, 2022 17:25

ryanofsky commented Jul 5, 2022

View reviewed changes

mzumsande reviewed Jul 7, 2022

View reviewed changes

fjahr reviewed Jul 10, 2022

View reviewed changes

DrahtBot mentioned this pull request Jul 13, 2022

[kernel 3b/n] Decouple {Dump,Load}Mempool from ArgsManager #25487

Merged

maflcko reviewed Jul 13, 2022

View reviewed changes

maflcko reviewed Jul 14, 2022

View reviewed changes

ryanofsky force-pushed the pr/ind branch from ddbbdcf to fb245ec Compare July 14, 2022 23:50

ryanofsky commented Jul 14, 2022

View reviewed changes

ryanofsky force-pushed the pr/ind branch from fb245ec to f678151 Compare July 15, 2022 04:04

maflcko reviewed Jul 15, 2022

View reviewed changes

DrahtBot mentioned this pull request Jul 15, 2022

[kernel 3c/n] Decouple validation cache initialization from ArgsManager #25527

Merged

ryanofsky force-pushed the pr/ind branch from f678151 to 8bc1602 Compare July 15, 2022 12:20

ryanofsky commented Jul 15, 2022

View reviewed changes

maflcko reviewed Jul 15, 2022

View reviewed changes

This was referenced Jul 15, 2022

refactor: Reduce number of LoadChainstate parameters and return values #25308

Merged

[kernel 3e/n] Decouple CDBWrapper and its kernel users from ArgsManager #25623

Closed

DrahtBot added the Needs rebase label Jul 18, 2022

ryanofsky added 7 commits July 18, 2022 13:39

indexes, refactor: Pass Chain interface instead of CChainState class …

33b4d48

…to indexes Passing abstract Chain interface will let indexes run in separate processes. This commit does not change behavior in any way.

indexes, refactor: Remove CBlockIndex* uses in coinstatsindex LookUpO…

addb4f2

…ne function This commit does not change behavior in any way.

indexes, refactor: Remove CBlockIndex* uses in index WriteBlock methods

dc971be

Replace WriteBlock method with CustomAppend and pass BlockInfo struct instead of CBlockIndex* pointer This commit does not change behavior in any way.

indexes, refactor: Remove CBlockIndex* uses in index Rewind methods

ee3a079

Replace Rewind method with CustomRewind and pass block hashes and heights instead of CBlockIndex* pointers This commit does not change behavior in any way.

ryanofsky force-pushed the pr/ind branch from 8bc1602 to 7878f97 Compare July 18, 2022 19:05

DrahtBot removed the Needs rebase label Jul 18, 2022

fanquake merged commit 92c8e18 into bitcoin:master Jul 19, 2022

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jul 20, 2022

Merge bitcoin#25494: indexes: Stop using node internal types

d5838f1

ryanofsky mentioned this pull request Mar 1, 2023

Fix BaseIndex::Commit false error #26903

Closed

ryanofsky mentioned this pull request May 18, 2023

index: make startup more efficient #27607

Merged

ryanofsky commented May 18, 2023

View reviewed changes

furszy mentioned this pull request May 22, 2023

index: prevent race by calling 'CustomInit' prior setting 'synced' flag #27720

Merged

ryanofsky mentioned this pull request Mar 19, 2024

index: avoid "failed to commit" errors on initialization #29671

Merged

bitcoin locked and limited conversation to collaborators May 17, 2024

		@@ -0,0 +1,23 @@
		// Copyright (c) 2022 The Bitcoin Core developers

indexes: Stop using node internal types #25494

indexes: Stop using node internal types #25494

Uh oh!

Conversation

Uh oh!

Uh oh!

Uh oh!

Conflicts

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

There was an error while loading. Please reload this page.