createwallet, loadwallet, unloadwallet and restorewallet) has been deprecated with the configuration option -deprecatedrpc=walletwarningfield in PR #27279 (released in v25.0). For the next release v26.0, the field and the configuration option can be removed.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | jonatack, achow101 |
| Stale ACK | kevkevinpal |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Reviewers, this pull request conflicts with the following ones:
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.
ACK d78f9a7
compiled and ran the code below and got the following response
0--> ./src/bitcoin-cli -regtest -named createwallet wallet_name=oops2 descriptors=false passphrase=""
1{
2 "name": "oops2",
3 "warnings": [
4 "Empty string given as passphrase, wallet will not be encrypted.",
5 "Wallet created successfully. The legacy wallet type is being deprecated and support for creating and opening legacy wallets will be removed in the future."
6 ]
7}
481@@ -491,9 +482,6 @@ static RPCHelpMan unloadwallet()
482 }
483 }
484 UniValue result(UniValue::VOBJ);
485- if (wallet->chain().rpcEnableDeprecated("walletwarningfield")) {
486- result.pushKV("warning", Join(warnings, Untranslated("\n")).original);
487- }
wallet for the deprecation.
UnloadWallet call and added you as co-author.
0@@ -0,0 +1,8 @@
1+Wallet
2+------
3+
4+- The `deprecatedrpc=walletwarningfield` configuration option has been removed.
5+ The `createwallet`, `loadwallet`, `restorewallet` and `unloadwallet` RPCs
6+ no longer return the "warning" string field. The same information can be
7+ accessed through the "warnings" field which returns a JSON array of strings.
Suggestions/fixups
s/can be accessed/is provided/
missing comma before “which”
s/single string field/“warning” string field/ seems clearer
perhaps mention when the “warnings” field was added
0 accessed with the "warnings" field added in v25.0, which returns a JSON array of strings.
Co-authored-by: Jon Atack <jon@atack.com>
Co-authored-by: Jon Atack <jon@atack.com>
