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/v2@v2.0.0-rc7/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/v2@v2.0.0-rc7/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/v2@v2.0.0-rc7/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/v2@v2.0.0-rc7/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.