Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FAB-11334] Scrubs partially constructed/deleted ledgers at peer init #2754

Merged

Conversation

jkneubuh
Copy link
Contributor

Peer init will now remove any ledger with status UNDER_CONSTRUCTION or UNDER_DELETION
at startup.

Signed-off-by: Josh Kneubuhl jkneubuh@us.ibm.com

Type of change

  • Improvement (improvement to code, performance, etc)

Description

Unjoining a peer from a channel will mark the ledger with status UNDER_DELETION
and proceed with the ledger removal. If the unjoin operation fails, the ledger
will include residue from the partial deletion, leaving the kvledger in a
questionable state. This commit forces the peer initialization to scan for any
ledgers with an UNDER_DELETION status, removing partial ledgers from the peer
at startup.

Additional details

Related issues

  • FAB-16035
  • FAB-4481
  • FAB-17787
  • FAB-17801

Unjoining a peer from a channel will mark the ledger with status UNDER_DELETION
and proceed with the ledger removal.  If the unjoin operation fails, the ledger
will include residue from the partial deletion, leaving the kvledger in a
questionable state.  This commit forces the peer initialization to scan for any
ledgers with an UNDER_DELETION status, removing partial ledgers from the peer.

Signed-off-by: Josh Kneubuhl <jkneubuh@us.ibm.com>
@jkneubuh jkneubuh requested a review from a team as a code owner July 14, 2021 18:49
Comment on lines +17 to +40
func TestDeleteUnderDeletionLedger(t *testing.T) {
conf, cleanup := testConfig(t)
conf.HistoryDBConfig.Enabled = true
defer cleanup()

provider := testutilNewProvider(conf, t, &mock.DeployedChaincodeInfoProvider{})
defer provider.Close()

// Set up a ledger and mark it as "under deletion." This emulates the
// state when a peer was in the process of unjoining a channel and the
// unjoin operation crashed mid delete.
ledgerID := constructTestLedger(t, provider, 0)
verifyLedgerIDExists(t, provider, ledgerID, msgs.Status_ACTIVE)

// doom the newly created ledger
require.NoError(t, provider.idStore.updateLedgerStatus(ledgerID, msgs.Status_UNDER_DELETION))
verifyLedgerIDExists(t, provider, ledgerID, msgs.Status_UNDER_DELETION)

// explicitly call the delete on the provider.
provider.deletePartialLedgers()

// goodbye, ledger.
verifyLedgerDoesNotExist(t, provider, ledgerID)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though, the extra test does not harm and in this particular case it's very small enough addition that could easily be ignored. However, in general we should prefer to be thoughtful of the purpose of an additional test.

  • It's hard to think of a bug/issue which would make this test pass while the fail the next one.
  • Neither does this test tests a separate section of the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants