validation: Improve error handling when VerifyDB dosn't finish successfully #25574

mzumsande · 2022-07-08T20:24:14Z

VerifyDB() can fail to complete due to insufficient dbcache at the level 3 checks. This PR improves the error handling in this case in the following ways:

The rpc -verifychain now returns false if the check can't be completed due to insufficient cache
During init, we only log a warning if the default values for -checkblocks and -checklevel are taken and the check doesn't complete. However, if the user actively specifies one of these args, we return with an InitError if we can't complete the check.

This PR also changes -verifychain RPC to return false if the verification didn't finish due to missing block data (pruning) or due to being interrupted by the node being shutdown.

Previously, this PR also included a fix for a possible assert during verification - this was done in #27009 (now merged).

saranshisatgit · 2022-07-09T03:31:34Z

I have tested the PR the command ./bitcoin-cli -signet verifychain 4 1000 returns true , does it requires tests to be written ?

maflcko · 2022-07-11T08:29:34Z

In the future the RPC can probably be extended with a "warnings" and "error" field, but this patch lgtm.

saranshisatgit · 2022-07-11T08:55:17Z

You mean changing the RPC return response prior adding objects for warning and error,

static RPCHelpMan verifychain()
if warning then (display Warning)
if error then  (display Error)
or else return response

It might require to or add new fields in the RPC?

This might mean that changing the way return is responding in RPC?

mzumsande · 2022-07-11T14:50:07Z

Note that this doesn't only affect the verifychain RPC, but is also called as part of the startup (with the default level 3), which prevent the node from starting if validation fails.
I think because of that, the current strategy is to only return an error if we are sure something is invalid, but permit the application to start with just a warning in the debug log if we couldn't complete all checks. If only the RPC was affected, it would be ok to just return an error if we weren't able to do all the checks we asked for.

saranshisatgit · 2022-07-12T13:18:05Z

verifychain

The above methods aborts, the code does produce assertion and thus abort, are you suggesting that it should rather identify for the user to simply ignore or warn the user that there is an issue with the verification of the chain, since we are starting up?

I was thinking to simply ignore the assertion or probably by pass the assertion by catching it some way rather abort() and probably it will help for the better and cleaner user inspection.

mzumsande · 2022-07-12T13:38:40Z

are you suggesting that it should rather identify for the user to simply ignore or warn the user that there is an issue with the verification of the chain, since we are starting up?

This PR reduces the number of checks that are being made when there is not sufficient ccache memory, so that the assertion can't hit anymore (assertions can't be ignored in general).
What I was talking about is what VerifyDB() should do if it didn't completely verify the blocks at the levels required (but also didn't encounter an actual error), and I explained why I think it is ok to give a warning in the debug log.

saranshisatgit · 2022-07-14T09:35:56Z

Right, so it should be taken care by default or by input, as in this there is an input , so that means a user is always triggering the output.

Now, this is my suggestion, that we should perhaps make this part of the default startup and should throw some debut output and continue with the startup process.?

What do you think? @mzumsande

mzumsande · 2022-07-14T18:14:41Z

Now, this is my suggestion, that we should perhaps make this part of the default startup and should throw some debut output and continue with the startup process.?

Not sure I understand. VerifyDB() is already part of the default startup, and this PR adds a debug log entry if we skip some L3 checks because if our ccache is insufficient.

saranshisatgit · 2022-07-15T10:57:40Z

I was under the assumption that you are talking about VerifyDB() handling the checks like the above on its own on the startup, rather the rpc doing the check !

DrahtBot · 2022-09-23T10:59:11Z

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

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	ryanofsky, john-moffett, MarcoFalke, achow101
Concept ACK	pablomartin4btc, hernanmarino
Stale ACK	fanquake

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#27125 (refactor, kernel: Decouple ArgsManager from blockstorage by TheCharlatan)
#25977 (refactor: Replace std::optional<bilingual_str> with util::Result by ryanofsky)
#25665 (refactor: Add util::Result failure values, multiple error and warning messages by ryanofsky)

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.

fanquake

ACK b7adbca2061e5a88130f61e2744885ab97340d5c - Could be improved in follow ups. i.e if a user has explictly set -checklevel=3||4, it's probably better to abort on too-small dbcache/where we can't actually perform the checks, rather than log a warning.

I also agree that changing verifychain to return warnings/errors is also a better behaviour than returning true (and just logging) when you've actually skipped level 3 & 4 checks.

src/validation.cpp

mzumsande · 2022-10-03T17:48:12Z

Happy to incorporate the suggestions from above here (no need for a follow-up).

mzumsande · 2022-10-07T17:07:53Z

I expanded this PR to incorporate the feedback (and rebased):
Additionally changed behavior:

The rpc -verifychain now returns false if the check can't be completed due to insufficient cache.
During init, we only log a warning if the default values for -checkblocks and -checklevel are taken and the check doesn't complete. However, if the user actively specifies one of these args, we return with an InitError.
Logging of verification progress is split over multiple lines. This is more verbose, but now each update has its own timestamp, and other threads logging concurrently will no longer lead to mangled output.

Will adjust OP and title.

src/rpc/blockchain.cpp

pablomartin4btc

Tested ACK, I've managed to reproduce the issue before the fix as follows in the screenshots:

From the bitcoind execution, level 3 & 4 from cli (which crashes it)

From the client terminal, level 3 or 4 both return true (this one before it crashes)

After applying the fix, both levels return false:

And bitcoind doesn't crash anymore (capturing both levels):

LarryRuane · 2022-12-07T16:36:33Z

Just FYI, I was unable to reproduce the problem with bitcoin-cli -signet verifychain 4 1000. However, it did reproduce when I increased the number of blocks to 5000. I'll review this PR soon.

hernanmarino

tested ACK , everything running as expected.

achow101 · 2023-01-05T20:03:14Z

ACK a1c83166f33d44a0909d8789d3a4bc8b2539842e

maflcko

review ACK a1c83166f33d44a0909d8789d3a4bc8b2539842e 💁

Show signature

Signature:

src/node/chainstate.cpp

src/validation.h

src/init.cpp

src/node/chainstate.h

src/validation.h

src/validation.cpp

ryanofsky

Code review ACK 42b192f0cbf9c04da111145c921344b0881b3ce3 with some suggestions and bikeshedding (feel free to ignore)

src/validation.cpp

src/validation.h

src/test/util/setup_common.cpp

src/validation.cpp

ryanofsky · 2023-02-16T15:36:20Z

src/node/chainstate.h

In commit "init, validation: Improve handling if VerifyDB() fails due to insufficient dbcache" (cf307244db97e7b9e29a3d0ff948a6fa7877b548)

true might be a safer default for libbitcoinkernel. Also the name of this option ChainstateLoadOptions::fail_on_insufficient_dbcache seems a little misleading because it seems like it is referring to insuffcient dbcache for loading, not insufficient_dbcache for verification. Would maybe change it to ChainstateLoadOptions::require_full_verification with a comment that setting the option to false can allow using a smaller dbcache size.

changed to ChainstateLoadOptions::fail_on_insufficient_dbcache
also changed the default, although it's never used because the bool is set during init.

I don't understand the comment. require_full_verification is not an option the user can set, it's value is determined by -checkblocks and -checklevel. So if a user wants to run with an extremely low dbcache, they should change those parameters (or just keep the default so that init will only warn).

re: #25574 (comment)

Thanks for implementing the suggestion. This comment was not about bitcoind, but about code that uses libbitcoinkernel such as:

bitcoin/src/bitcoin-chainstate.cpp

Lines 93 to 96 in fe1b325

node::ChainstateLoadOptions options;

options.check_interrupt = [] { return false; };

auto [status, error] = node::LoadChainstate(chainman, cache_sizes, options);

if (status != node::ChainstateLoadStatus::SUCCESS) {

Code like this has it's own options and defaults, and is not aware of checkblocks or checklevel. It is just calling and using the LoadChainstate function directly. From the perspective of a LoadChainstate caller, I think fail_on_insufficient_dbcache could have been misleading because it sounds like it would allow loading with an insufficient dbcache, not just verifying with an insufficient dbcache. I do think in either case it wouldn't be bad for the option to have a code comment, so I suggested one below.

This does not change behavior. It is in preparation for special handling of the case where VerifyDB doesn't finish for various reasons, but doesn't fail.

…terrupted This means that the -verifydb RPC will now return false if it cannot finish due to the node being shutdown.

…cient dbcache The rpc command verifychain now fails if the dbcache was not sufficient to complete the verification at the specified level and depth. In the same situation, the VerifyDB check during Init will now fail (and lead to an early shutdown) if the user has explicitly specified -checkblocks or -checklevel but the check couldn't be executed because of the limited cache. If the user didn't change any of the two and is using the defaults, log a warning but don't prevent the node from starting up.

Now the verifychain RPC returns false if the checks didn't finish because the blocks requested to be queried have been pruned.

mzumsande · 2023-02-16T23:17:59Z

42b192f to 0af16e7:

Addressed comments by @MarcoFalke and @ryanofsky, thanks for the reviews!
Also changed title and adjusted OP since this is no longer just about -dbcache-related error handling.

ryanofsky

Code review ACK 0af16e7. Only small suggested changes since the last review, like renaming some of the enum values. I did leave more suggestions, but they are not very important and could be followups

src/validation.cpp

ryanofsky · 2023-02-17T16:03:53Z

src/node/chainstate.h

re: #25574 (comment)

Thanks for implementing the suggestion. This comment was not about bitcoind, but about code that uses libbitcoinkernel such as:

bitcoin/src/bitcoin-chainstate.cpp

Lines 93 to 96 in fe1b325

node::ChainstateLoadOptions options;

options.check_interrupt = [] { return false; };

auto [status, error] = node::LoadChainstate(chainman, cache_sizes, options);

if (status != node::ChainstateLoadStatus::SUCCESS) {

Code like this has it's own options and defaults, and is not aware of checkblocks or checklevel. It is just calling and using the LoadChainstate function directly. From the perspective of a LoadChainstate caller, I think fail_on_insufficient_dbcache could have been misleading because it sounds like it would allow loading with an insufficient dbcache, not just verifying with an insufficient dbcache. I do think in either case it wouldn't be bad for the option to have a code comment, so I suggested one below.

ryanofsky · 2023-02-17T16:15:35Z

src/node/chainstate.h

    bool reindex{false};
    bool reindex_chainstate{false};
    bool prune{false};
+    bool require_full_verification{true};


In commit "init, validation: Improve handling if VerifyDB() fails due to insufficient dbcache" (0c7785b)

Might be worth adding a comment to explain why you would set the option. Maybe:

//! Setting require_full_verification to true will require all checks at //! check_level (below) to succeed for loading to succeed. Setting it to //! false will skip checks if cache is not big enough to run them, so may be //! helpful for running with a small cache.

ryanofsky · 2023-02-17T16:21:10Z

src/validation.cpp

        // check level 0: read from disk
        if (!ReadBlockFromDisk(block, pindex, consensus_params)) {
-            return error("VerifyDB(): *** ReadBlockFromDisk failed at %d, hash=%s", pindex->nHeight, pindex->GetBlockHash().ToString());
+            LogPrintf("Verification error: ReadBlockFromDisk failed at %d, hash=%s\n", pindex->nHeight, pindex->GetBlockHash().ToString());


In commit "validation: Change return value of VerifyDB to enum type" (6360b53)

Commit message says this does not change behavior, but this is changing log prints slightly replacing VerifyDB(): prefix with Verification error:. This is probably a good change, but could be clarified in the commit message.

ryanofsky · 2023-02-17T16:34:20Z

src/node/chainstate.cpp

                options.check_blocks);
            switch (result) {
            case VerifyDBResult::SUCCESS:
+            case VerifyDBResult::INTERRUPTED:


In commit "validation: return VerifyDBResult::INTERRUPTED if verification was interrupted" (d6f781f)

It would be less surprising to have VerifyDBResult::INTERRUPTED return ChainstateLoadStatus::INTERRUPTED than ChainstateLoadStatus::SUCCESS. Another potentially good side effect would be that it would avoid the caller printing a misleading load time if the load didn't really succeed:

bitcoin/src/init.cpp

Lines 1520 to 1524 in fe1b325

std::tie(status, error) = catch_exceptions([&]{ return VerifyLoadedChainstate(chainman, options);});

if (status == node::ChainstateLoadStatus::SUCCESS) {

fLoaded = true;

LogPrintf(" block index %15dms\n", Ticks<std::chrono::milliseconds>(SteadyClock::now() - load_block_index_start_time));

}

Makes sense - I'll open a small follow-up to address this in a few days.

john-moffett

ACK 0af16e7

maflcko

lgtm re-ACK 0af16e7 🎚

Show signature

Signature:

maflcko · 2023-02-22T11:44:29Z

src/validation.h

 enum class VerifyDBResult {
    SUCCESS,
    CORRUPTED_BLOCK_DB,
+    INTERRUPTED,


nit in d6f781f (commit message), only if you retouch:

I think the rpc is called verifychain and not -verifydb?

achow101 · 2023-02-22T19:10:12Z

ACK 0af16e7

… dosn't…

…RUPTED when verification was interrupted. c5825e1 doc: add explanation for fail_on_insufficient_dbcache (Ryan Ofsky) 7dff7da init: Return more fitting ChainStateLoadStatus if verification was interrupted (Martin Zumsande) Pull request description: This addresses two outstanding comments by ryanofsky from #25574: * return `ChainstateLoadStatus::INTERRUPTED` instead of `ChainstateLoadStatus::SUCCESS` if verification was stopped by an interrupt. This would coincide with straightforward expectation, and it avoids a misleading [log entry](https://github.com/mzumsande/bitcoin/blob/c5825e14f8999a8c5f5121027af9e07ac51ab42e/src/init.cpp#L1526) in `init` for the block index load time (because that would include the verificiation, which didn't complete). It shouldn't affect node behavior otherwise because the shutdown signal would be caught in init anyway. In test, this would lead to an assert ([link](https://github.com/mzumsande/bitcoin/blob/c5825e14f8999a8c5f5121027af9e07ac51ab42e/src/test/util/setup_common.cpp#L230)), which also makes more sense because benign interrupts are not expected there during init. This can be tested by setting a large value for `-checkblocks`, interrupting the node during block verification and observing the log. bitcoin/bitcoin#25574 (comment) * add documentation for `require_full_verification` bitcoin/bitcoin#25574 (comment) ACKs for top commit: MarcoFalke: thanks lgtm ACK c5825e1 Tree-SHA512: ca1c71a1b046d30083337dd9ef6d52e66fa1ac8c4ecd807716e4aa6a894179a81df41caee916fa30997fd6e0b284412a3c8f2919d19c29d826fb580ffb89fd73

…hen verification was interrupted. c5825e1 doc: add explanation for fail_on_insufficient_dbcache (Ryan Ofsky) 7dff7da init: Return more fitting ChainStateLoadStatus if verification was interrupted (Martin Zumsande) Pull request description: This addresses two outstanding comments by ryanofsky from bitcoin#25574: * return `ChainstateLoadStatus::INTERRUPTED` instead of `ChainstateLoadStatus::SUCCESS` if verification was stopped by an interrupt. This would coincide with straightforward expectation, and it avoids a misleading [log entry](https://github.com/mzumsande/bitcoin/blob/c5825e14f8999a8c5f5121027af9e07ac51ab42e/src/init.cpp#L1526) in `init` for the block index load time (because that would include the verificiation, which didn't complete). It shouldn't affect node behavior otherwise because the shutdown signal would be caught in init anyway. In test, this would lead to an assert ([link](https://github.com/mzumsande/bitcoin/blob/c5825e14f8999a8c5f5121027af9e07ac51ab42e/src/test/util/setup_common.cpp#L230)), which also makes more sense because benign interrupts are not expected there during init. This can be tested by setting a large value for `-checkblocks`, interrupting the node during block verification and observing the log. bitcoin#25574 (comment) * add documentation for `require_full_verification` bitcoin#25574 (comment) ACKs for top commit: MarcoFalke: thanks lgtm ACK c5825e1 Tree-SHA512: ca1c71a1b046d30083337dd9ef6d52e66fa1ac8c4ecd807716e4aa6a894179a81df41caee916fa30997fd6e0b284412a3c8f2919d19c29d826fb580ffb89fd73

Summary: This does not change behavior. It is in preparation for special handling of the case where VerifyDB doesn't finish for various reasons, but doesn't fail. This is a backport of [[bitcoin/bitcoin#25574 | core#25574]] bitcoin/bitcoin@6360b53 Depends on D14925 Test Plan: `ninja all check-all` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D14926

…terrupted Summary: This means that the verifydb RPC will now return false if it cannot finish due to the node being shutdown. This also avoids a misleading block index loadtime log entry in init. This is a partial backport of [[bitcoin/bitcoin#25574 | core#25574]] and [[bitcoin/bitcoin#27157 | core#27157]] bitcoin/bitcoin@d6f781f bitcoin/bitcoin@7dff7da Depends on D14926 Test Plan: Co-authored-by: Ryan Ofsky <[email protected]> `src/bitcoind checkblocks` Press Ctrl-C, check that it still exits gracefully and does not print a success message for the block verification or block loading. Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D14927

…cient dbcache Summary: The rpc command verifychain now fails if the dbcache was not sufficient to complete the verification at the specified level and depth. In the same situation, the VerifyDB check during Init will now fail (and lead to an early shutdown) if the user has explicitly specified -checkblocks or -checklevel but the check couldn't be executed because of the limited cache. If the user didn't change any of the two and is using the defaults, log a warning but don't prevent the node from starting up. This is a partial backport of [[bitcoin/bitcoin#25574 | core#25574]] bitcoin/bitcoin@0c7785b Depends on D14927 Test Plan: ``` $ src/bitcoin-cli verifychain 4 10000 false ``` ``` $ src/bitcoind -dbcache=10 ... 2023-12-06T13:33:04Z Verifying last 10000 blocks at level 4 2023-12-06T13:33:04Z Verification progress: 0% 2023-12-06T13:33:04Z Verification progress: 10% 2023-12-06T13:33:04Z Verification progress: 20% 2023-12-06T13:33:04Z Verification progress: 30% 2023-12-06T13:33:04Z Verification progress: 40% 2023-12-06T13:33:04Z Verification progress: 50% 2023-12-06T13:33:04Z Skipped verification of level >=3 (insufficient database cache size). Consider increasing -dbcache. ... ``` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D14928

Summary: Now the verifychain RPC returns false if the checks didn't finish because the blocks requested to be queried have been pruned. This is a partial backport of [[bitcoin/bitcoin#25574 | core#25574]] bitcoin/bitcoin@57ef2a4 Depends on D14928 Test Plan: `ninja && ninja check-functional` Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Differential Revision: https://reviews.bitcoinabc.org/D14929

…successfully Summary: This concludes backport of [[bitcoin/bitcoin#25574 | core#25574]] Test Plan: proof reading Reviewers: #bitcoin_abc, Fabien, bytesofman Reviewed By: #bitcoin_abc, Fabien, bytesofman Subscribers: bytesofman, Fabien Differential Revision: https://reviews.bitcoinabc.org/D14930

fanquake added the Validation label Jul 8, 2022

fanquake approved these changes Oct 3, 2022

View reviewed changes

src/validation.cpp Outdated Show resolved Hide resolved

mzumsande force-pushed the 202207_verifychain branch 2 times, most recently from 57f367a to ad2a1f8 Compare October 7, 2022 17:05

mzumsande force-pushed the 202207_verifychain branch from ad2a1f8 to a1c8316 Compare October 7, 2022 17:13

mzumsande changed the title ~~validation: Skip VerifyDB checks of level >=3 if dbcache is too small~~ validation: Improve error handling when VerifyDB fails due to insufficient dbcache Oct 7, 2022

This was referenced Oct 7, 2022

refactor: Replace std::optional<bilingual_str> with util::Result #25977

Merged

refactor: Add util::Result failure types and ability to merge result values #25665

Open

This was referenced Oct 17, 2022

refactor: Use util::Result class for wallet loading #25722

Draft

Drop IO priority to idle while reading blocks for peer requests and startup verification #9245

Closed

pablomartin4btc reviewed Dec 6, 2022

View reviewed changes

src/rpc/blockchain.cpp Outdated Show resolved Hide resolved

pablomartin4btc reviewed Dec 6, 2022

View reviewed changes

fanquake added this to the 25.0 milestone Dec 7, 2022

DrahtBot mentioned this pull request Dec 7, 2022

Remove almost all blockstorage globals #25781

Merged

hernanmarino reviewed Dec 8, 2022

View reviewed changes

maflcko approved these changes Jan 6, 2023

View reviewed changes

ryanofsky approved these changes Feb 16, 2023

View reviewed changes

src/validation.cpp Outdated Show resolved Hide resolved

src/validation.h Outdated Show resolved Hide resolved

src/test/util/setup_common.cpp Outdated Show resolved Hide resolved

src/validation.cpp Outdated Show resolved Hide resolved

ryanofsky reviewed Feb 16, 2023

View reviewed changes

mzumsande added 2 commits February 16, 2023 17:29

validation: Change return value of VerifyDB to enum type

6360b53

This does not change behavior. It is in preparation for special handling of the case where VerifyDB doesn't finish for various reasons, but doesn't fail.

validation: return VerifyDBResult::INTERRUPTED if verification was in…

d6f781f

…terrupted This means that the -verifydb RPC will now return false if it cannot finish due to the node being shutdown.

mzumsande force-pushed the 202207_verifychain branch from 42b192f to 8f4753a Compare February 16, 2023 22:41

mzumsande changed the title ~~validation: Improve error handling when VerifyDB fails due to insufficient dbcache~~ validation: Improve error handling when VerifyDB dosn't finish successfully Feb 16, 2023

mzumsande added 3 commits February 16, 2023 17:58

validation: report if pruning prevents completion of verification

57ef2a4

Now the verifychain RPC returns false if the checks didn't finish because the blocks requested to be queried have been pruned.

doc: add release note for bitcoin#25574

0af16e7

mzumsande force-pushed the 202207_verifychain branch from 8f4753a to 0af16e7 Compare February 16, 2023 23:04

ryanofsky approved these changes Feb 17, 2023

View reviewed changes

DrahtBot requested a review from john-moffett February 17, 2023 16:45

DrahtBot mentioned this pull request Feb 19, 2023

refactor, kernel: Decouple ArgsManager from blockstorage #27125

Merged

john-moffett approved these changes Feb 21, 2023

View reviewed changes

maflcko approved these changes Feb 22, 2023

View reviewed changes

achow101 merged commit 832fa2d into bitcoin:master Feb 22, 2023

mzumsande mentioned this pull request Feb 24, 2023

init: Return ChainstateLoadStatus::INTERRUPTED when verification was interrupted. #27157

Merged

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Feb 25, 2023

Merge bitcoin#25574: validation: Improve error handling when VerifyDB…

51bb903

… dosn't…

mzumsande deleted the 202207_verifychain branch May 4, 2023 16:41

bitcoin locked and limited conversation to collaborators May 3, 2024

	node::ChainstateLoadOptions options;
	options.check_interrupt = [] { return false; };
	auto [status, error] = node::LoadChainstate(chainman, cache_sizes, options);
	if (status != node::ChainstateLoadStatus::SUCCESS) {

	std::tie(status, error) = catch_exceptions([&]{ return VerifyLoadedChainstate(chainman, options);});
	if (status == node::ChainstateLoadStatus::SUCCESS) {
	fLoaded = true;
	LogPrintf(" block index %15dms\n", Ticks<std::chrono::milliseconds>(SteadyClock::now() - load_block_index_start_time));
	}

validation: Improve error handling when VerifyDB dosn't finish successfully #25574

validation: Improve error handling when VerifyDB dosn't finish successfully #25574

Uh oh!

Conversation

mzumsande commented Jul 8, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

saranshisatgit commented Jul 9, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maflcko commented Jul 11, 2022

Uh oh!

saranshisatgit commented Jul 11, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mzumsande commented Jul 11, 2022

Uh oh!

saranshisatgit commented Jul 12, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mzumsande commented Jul 12, 2022

Uh oh!

saranshisatgit commented Jul 14, 2022

Uh oh!

mzumsande commented Jul 14, 2022

Uh oh!

saranshisatgit commented Jul 15, 2022

Uh oh!

DrahtBot commented Sep 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviews

Conflicts

Uh oh!

fanquake left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mzumsande commented Oct 3, 2022

Uh oh!

mzumsande commented Oct 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

pablomartin4btc left a comment

Choose a reason for hiding this comment

Uh oh!

LarryRuane commented Dec 7, 2022

Uh oh!

hernanmarino left a comment

Choose a reason for hiding this comment

Uh oh!

achow101 commented Jan 5, 2023

Uh oh!

maflcko left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ryanofsky left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mzumsande Feb 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mzumsande commented Feb 16, 2023

Uh oh!

mzumsande commented Jul 8, 2022 •

edited

Loading

saranshisatgit commented Jul 9, 2022 •

edited

Loading

saranshisatgit commented Jul 11, 2022 •

edited

Loading

saranshisatgit commented Jul 12, 2022 •

edited

Loading

DrahtBot commented Sep 23, 2022 •

edited

Loading

mzumsande commented Oct 7, 2022 •

edited

Loading

mzumsande Feb 16, 2023 •

edited

Loading