This is the error I get:

```
$ bitcoin-cli -rpcwallet=descriptor -testnet upgradewallet                         <
error code: -1
error message:
wallet/rpcwallet.cpp:4522 (operator())
Internal bug detected: '!error.empty()'
You may report this issue here: https://github.com/bitcoin/bitcoin/issues
```

The daemon logs this:

```
2021-07-15T16:16:54Z [descriptor] Performing wallet upgrade to 169900
```

**Expected behavior**

When I do the same on the default (non-descriptor) wallet:

```
$ bitcoin-cli -rpcwallet="" -testnet upgradewallet                             
{
  "wallet_name": "",
  "previous_version": 169900,
  "current_version": 169900,
  "result": "Already at latest version. Wallet version unchanged."
}
```

<!-- **Actual behavior** -->

<!-- See above. Isn't this kind of backwards, to first ask what I expect and then ask what I got? I am writing here because I got something strange in the first place... -->

**System information**

Bitcoin Core v0.21.1 Linux x86_64 glibc (Ubuntu) using binarias from bitcoincore.org

* A keypool also allowed encrypted wallets to give out addresses without
 * having to be decrypted to generate a new private key.
 *
 * With the introduction of HD wallets (commit: f1902510), the keypool
 * essentially became an address look-ahead pool. Restoring old backups can no
 * longer definitively lose funds as long as the addresses used were from the
 * wallet's HD seed (since all private keys can be rederived from the seed).
 * However, if many addresses were used since the backup, then the wallet may
 * not know how far ahead in the HD chain to look for its addresses. The
 * keypool is used to implement a 'gap limit'. The keypool maintains a set of
 * keys (by default 1000) ahead of the last used key and scans for the
 * addresses of those keys.  This avoids the risk of not seeing transactions
 * involving the wallet's addresses, or of re-using the same address.
 * In the unlikely case where none of the addresses in the `gap limit` are
 * used on-chain, the look-ahead will not be incremented to keep
 * a constant size and addresses beyond this range will not be detected by an
 * old backup. For this reason, it is not recommended to decrease keypool size
 * lower than default value.
 *
 * The HD-split wallet feature added a second keypool (commit: 02592f4c). There
 * is an external keypool (for addresses to hand out) and an internal keypool
 * (for change addresses).
 *
 * Keypool keys are stored in the wallet/keystore's keymap. The keypool data is
 * stored as sets of indexes in the wallet (setInternalKeyPool,
 * setExternalKeyPool and set_pre_split_keypool), and a map from the key to the
 * index (m_pool_key_to_index). The CKeyPool object is used to
 * serialize/deserialize the pool data to/from the database.
 */
class CKeyPool