panic: runtime error: invalid memory address or nil pointer dereference

[simlecode]

https://github.com/filecoin-project/go-data-transfer/blob/master/impl/impl.go#L405

error log

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1eb4142]

goroutine 325 [running]:
github.com/filecoin-project/go-data-transfer/v2.ValidationResult.LeaveRequestPaused({0x0, 0xc000a8f8a0, 0x0, 0x0, 0x0}, {0x0, 0x0})
        /root/go/pkg/mod/github.com/filecoin-project/go-data-transfer/[email protected]/manager.go:50 +0xc2
github.com/filecoin-project/go-data-transfer/v2/impl.(*manager).handleTransportUpdate(0xc000c7ea20, {0x648dbd8, 0xc000c1acc0}, {0x0, 0x0}, {0x0, 0x0}, {0x0, 0xc000a8f8a0, 0x0, ...}, ...)
        /root/go/pkg/mod/github.com/filecoin-project/go-data-transfer/[email protected]/impl/impl.go:456 +0xb4
github.com/filecoin-project/go-data-transfer/v2/impl.(*manager).updateValidationStatus(0xc000c7ea20, {0x648dbd8, 0xc000c1acc0}, {{0xc0044a3d10, 0x26}, {0xc0044a3d40, 0x26}, 0x1779a0855403df44}, {0x0, 0xc000a8f8a0, ...})
        /root/go/pkg/mod/github.com/filecoin-project/go-data-transfer/[email protected]/impl/impl.go:408 +0x2e9
github.com/filecoin-project/go-data-transfer/v2/impl.(*manager).UpdateValidationStatus(0xc000c7ea20, {0x648dbd8, 0xc000c1acc0}, {{0xc0044a3d10, 0x26}, {0xc0044a3d40, 0x26}, 0x1779a0855403df44}, {0x0, 0xc000a8f8a0, ...})
        /root/go/pkg/mod/github.com/filecoin-project/go-data-transfer/[email protected]/impl/impl.go:386 +0x44a
github.com/ipfs-force-community/droplet/v2/retrievalprovider.(*providerDealEnvironment).UpdateValidationStatus(0xc0005b2710, {0x648db68, 0xc0000561b0}, {{0xc0044a3d10, 0x26}, {0xc0044a3d40, 0x26}, 0x1779a0855403df44}, {0x0, 0xc000a8f8a0, ...})
        /root/droplet/retrievalprovider/provider_environments.go:123 +0xed
github.com/ipfs-force-community/droplet/v2/retrievalprovider.(*RetrievalDealHandler).UpdateFunding(0xc000c90f00, {0x648db68, 0xc0000561b0}, 0xc0044d48f0)

[rvagg]

It'd be interesting to see what the error is that's causing this!

You're right though, I think the err needs to be handled here, rather than passed in to handleTransportUpdate which relies on chst to do anything meaningful, including handling the resultErr argument. Alternatively, perhaps we need to pass in the ChannelID to handleTransportUpdate so we don't need chst.