[BUG] lotus client has zero active transfers, but refuses retrievals because of active transfer

[ghost]

Describe the bug
lotus client list-transfers shows no current transfers, but then my retrieval fails with Retrieve failed: there is an active retrieval deal with peer <peer id>. Here's an example:

$ lotus client list-transfers
Sending Channels

Receiving Channels

$ lotus client retrieve --miner f08399 QmZJZk86RRGaAJu2rgLBS6RbvTJzRTzA8zdjvJ5V1cvb7g /dev/null
> Recv: 0 B, Paid 0 FIL, ClientEventOpen (DealStatusNew)
ERROR: retrieval failed: Retrieve failed: there is an active retrieval deal with peer 12D3KooWGabRFTsGhQLP5sb5f6eSUDbhyDqiF3fK9mZQWxJK5xJG for payload CID QmZJZk86RRGaAJu2rgLBS6RbvTJzRTzA8zdjvJ5V1cvb7g (retrieval deal ID 1622031587337027948, state DealStatusOngoing) - existing deal must be cancelled before starting a new retrieval deal

$ lotus client list-transfers
Sending Channels

Receiving Channels

Version (run lotus version):

$ lotus version
Daemon:  1.11.0-dev+mainnet+git.3cdd06b71+api1.3.0
Local: lotus version 1.11.0-dev+mainnet+git.3cdd06b71

To Reproduce
See original bug description above

Expected behavior
If lotus client list-transfers is empty, then I should never see an error message recommending existing deal must be cancelled before starting a new retrieval deal. It's inconsistent.

[ghost]

Log
lotus-issue-6346.log

[dirkmc]

@mgoelzer do you see the transfer if you run lotus client list-transfers --completed --show-failed?

When you get the error message that there is already an active retrieval deal, it should tell you the id of the retrieval deal. You can pass that id to cancel-retrieval to cancel the deal:
lotus client cancel-retrieval --deal-id=<deal ID>

[TippyFlitsUK]

Resolved by following @dirkmc's recommendation.