Deal stuck in StorageDealCheckForAcceptance state

[dineshshenoy]

A deal from Textile has been stuck in StorageDealCheckForAcceptance for 1 day, even though the Lotus version was recently upgraded. This is happening with a PL'miner (run by Marcus) - f02665

DealDate: Nov 10 12:07:09
DealCid: bafyreic6qjalcljw2ovod5jfchh5ar3vklcgfq5z64nf5j5e4eecujuifq
DealId: 0
Provider: f02665
State: StorageDealCheckForAcceptance
On Chain? N
Slashed? N
PieceCID: baga6ea4seaqfsgmrp2iyo4tpfy5o62rfcpgixy74z5a6jqru34sdeqr4ovoxkei
Size: 7.938 GiB
Price: 0.002085872 FIL
Duration: 521468
Verified: false

Version (run lotus version):
lotus version 1.1.2+git.f225b7b92

Additional context
Deals are being tracked here: http://13.68.239.146:9090/deals.txt and updated every 10 minutes

[kernelogic]

I have hundreds of deals stuck in StorageDealCheckForAcceptance state...

lotus client deal-stats
Total: 2568 deals, 4.933 TiB
StorageDealActive: 351 deals, 691.3 GiB
StorageDealSealing: 601 deals, 1.156 TiB
StorageDealFundsReserved: 19 deals, 37.7 GiB
StorageDealCheckForAcceptance: 377 deals, 744.6 GiB
StorageDealStartDataTransfer: 4 deals, 7.938 GiB
StorageDealTransferring: 4 deals, 7.938 GiB
StorageDealError: 1185 deals, 2.27 TiB
StorageDealClientTransferRestart: 27 deals, 53.58 GiB

[dirkmc]

@kernelogic When deals are in StorageDealCheckForAcceptance on the client side, it means the client is waiting for the provider to publish the deal. The client periodically sends a message to the provider asking for the deal status.
On the provider side it needs to:

• Verify that the data matches the expected CID
• Reserve funds for the deal
• Publish the deal
• Wait for the published deal to appear on chain

If there is chain congestion it could mean the provider takes longer than usual to be able to send out messages (eg for reserving funds / publishing).

Have you seen any progress on these deals you mentioned that are stuck in StorageDealCheckForAcceptance?

[dineshshenoy]

Related: #5062

[dirkmc]

Closing as it should be possible to cancel deals by cancelling the associated data transfer: #5032