fix(chart.ts): pending channel display bug

[amovfx]

Channel info now displays proper source and dest names
for pending channels

Closes #699

Description

Channel links are proccessed twice resulting in data being clobbered.

Steps to Test

1. Launch terminal for alice
2. Run lncli openchannel <bob-pubkey> 100000
3. Check channel details

Screenshots

[Only if applicable]

[amovfx]

@jamaljsr
You might want to take a look at this a bit more closely, it was subtle. I'm also curious if taro is going to need this. I don't think so because the links can't really be changed after the network starts.

ALso, out of scope. Maybe a pending channel link could use the functionality to quickly confirm the channel with mining 6 blocks and refreshing the chart? WDT?

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (bd93e13) 100.00% compared to head (162f1e5) 100.00%.

Additional details and impacted files

@@            Coverage Diff            @@
##            master      #703   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          116       116           
  Lines         3435      3437    +2     
  Branches       619       647   +28     
=========================================
+ Hits          3435      3437    +2     

Impacted Files	Coverage Δ
src/lib/lightning/lnd/lndService.ts	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jamaljsr]

Thanks for investigating and submitting this PR.

While this solution does work in this specific scenario, it's not addressing the root cause of the problem. If you look at LndService.getChannels(), you'll see that for open channels it's only returning the channels that were opened by the supplied node, whereas for the other pending channels it's not filtering out the channels initiated by other nodes.

polar/src/lib/lightning/lnd/lndService.ts

Lines 49 to 55 in 6445103

	return [
	...open.filter(c => c.initiator).map(mapOpenChannel),
	...opening.map(pluckChan).map(mapPendingChannel('Opening')),
	...closing.map(pluckChan).map(mapPendingChannel('Closing')),
	...forceClosing.map(pluckChan).map(mapPendingChannel('Force Closing')),
	...waitingClose.map(pluckChan).map(mapPendingChannel('Waiting to Close')),
	];

So when the chart links are being created, the same pending channel is present for both nodes. This causes the link created for alice to be overwritten by the link created for bob. Your fix does work because it prevents bob's channel from overwriting alice's, but now the inverse situation becomes a bug. Currently if you open the channel from bob to alice, the pending channel will show the correct source and destination. When using your fix, the bug returns as it now shows the source as alice, since bob's channel is being filtered out.

The better solution here would be to address the root cause of the problem, which is that LndService.getChannels() is returning channels that were not initiated by the node provided when they are pending. The LND.PendingChannel type does have an initiator field which it can inspect to see if the value is LND.Initiator.INITIATOR_LOCAL.

[amovfx]

Thanks for the guidance, I was looking at this function for a period of time as a root cause but couldn't identify the solution you pointed out, I'll update this asap.

[jamaljsr]

This won't work because LND.Channel.initiator is a boolean, but the isChanInitiatorLocal function is comparing it to an enum/number. That function looks good for all of the pending arrays below, but the open channels array has a different type so it should be filtered differently.

[amovfx]

Ah ty!

[jamaljsr]

The code looks good. I'll test it when I get a chance.

Can you squash your commits into one and use a proper message prefix fix(lnd): ...

[jamaljsr]

Tested and confirmed this resolves the issue. Just needs a squash then this can be merged.

[amovfx]

Fantastic, thanks for the guidance and feedback once again.