Fix: PaychGetRestartAfterAddFundsMsg may stuck in forever waiting

[zl03jsj]

TestPaychGetRestartAfterAddFundsMsg may stuck in forever waiting

as following state diagram shows:

stateDiagram-v2
  state "pm.store.WithPendingAddFunds"  as queryMsgFromStore
  Test: TestPaychGetRestartAfterAddFundsMsg
  state "_, mcid2, err := : mgr.GetPaych(ctx, from, to, amt2)"as GetPaych
  waitForAddFundsMsg:channelAccessor.waitForAddFundsMsg
  state "mockPaychAPI.WaitMsg(mcid2..." as WaitMsg
  state "receipt := <- response " as waitReceiptResponse
  concurrency: concurrency operations
  state  "mgr2, err := newManager(...)" as Mgr2
  state "done := make(chan struct{})
pchapi.waitingResponses[mcid] = &waitingResponse{receipt: receipt, done: done}
pchapi.lk.Unlock()
<-done
" as WaitCode
  
  Test --> GetPaych
  GetPaych --> channelAccessor.GetPaych
  channelAccessor.GetPaych --> channelAccessor.addFunds: this is started by mgr1, in another go-routine
  channelAccessor.GetPaych --> mock.close
mock.close --> Mgr2
Mgr2 --> manager.Start
mock.close --> waitReceiptResponse: Msg `mcid2` received receipt,\nthis will unblock the waiting
note left of waitReceiptResponse
            blocked here, waiting for Receipt of `mcid2` to continue
        end note

state concurrency {
  channelAccessor.addFunds --> waitForAddFundsMsg
  waitForAddFundsMsg --> WaitMsg
  WaitMsg --> waitReceiptResponse
waitReceiptResponse --> channelAccessor.mutateChannelInfo: ChannelInfo.AddFundsMsg = nil
channelAccessor.mutateChannelInfo --> store.SaveChannelInfo: actually the message of `mcid2`, is set as complete.
note right of store.SaveChannelInfo 
marked as C
end note
--
manager.Start --> manager.restartPending
manager.restartPending --> queryMsgFromStore
note right of queryMsgFromStore
            read uncompleted `AddFunds` Messages from store, re-waiting receipts on chain
        end note
queryMsgFromStore --> mockPaychAPI.WaitMsg(mcid2,..: run in go-routine
queryMsgFromStore --> mockPaychAPI.receiveMsgResponse(mcid2,...
mockPaychAPI.receiveMsgResponse(mcid2,... --> WaitCode

note right of mockPaychAPI.WaitMsg(mcid2,..
marked as A
end note
note right of WaitCode 
marked as B
end note
}

Loading

the A, B, C are execute asynchronously, their execution order are unpredictable.
if the order is in bad path: C -> B,
in that case, the A(mockPaychAPI.StateWaitMsg of mcid2) would never happen,
the B would blocked by receiveMsgResponse(mcid2, )

lotus/paychmgr/paychget_test.go

Lines 646 to 649 in e3f1eb2

	mock2.receiveMsgResponse(mcid2, types.MessageReceipt{
	ExitCode: 0,
	Return: []byte{},
	})

waiting <-done forever. the test would fail of timeout.

[magik6k]

This makes sense. Thanks a lot for the PR!