More details about ExpectedPaymentFeesPaid error

[bucko13]

I was wondering if I could get some more insight into this particular error: ExpectedPaymentFeesPaid.

I'm getting it when trying to pay a payreq with ln-service from within a serverless function deployment. When trying to pay invoices created in the same circumstances, to the same node, and from the same node but with the cli or another client (e.g. lightning joule), it seems to go through ok. And actually even with ln-service I can pay invoices normally, but there is a narrow circumstance where I'm running this in a serverless lambda function (zeit's now service to be exact, which runs on top of AWS) and for whatever reason I'm always getting this error when the invoice is attempted to be paid. I was hoping some more details about the error might help debug this further. Even the same code but running as a simple node script/server everything works, it's just when in the lambda deployment (both local and remote, they have a local deployment option that simulates running it on their servers).

Thanks!

[alexbosworth]

That could happen if the environment is different somehow and you get back a number instead of a string for a fee paid

[alexbosworth]

I would try changing the error check to check for undefined instead of falsey

[bucko13]

I think that did it. Thanks!

Could you explain what you meant by the environment being different? Which environments and different how?

[alexbosworth]

gRPC is not straightforward like JSON+REST in that there is a backing file you can look at and simple JSON types. What you get back with gRPC differs from platform to platform

My guess is that on some platforms, the gRPC implementation is giving back numbers for int64 values, and on other platforms it is giving back strings. A 0 fee number will be falsey and a 0 fee string will not be

It could signal some bad news if you are getting back int64s as numbers because in some situations the Javascript Number will not be able to handle an int64 because it's too high and start representing incorrect values

If this guess is correct, potentially it is related to this issue on lnd: https://github.com/lightningnetwork/lnd/pull/2352

[bucko13]

Fantastic. Thanks for the explanation. That makes a lot of sense. I'm still testing as I'm having some problems with my channels at the moment, but will close for now as this seems to have resolved the issue.

[bucko13]

So unfortunately it got past the Payment Fees error but then ran into the next one still: ExpectedPaymentFeesPaidInMillitokens.

I was also thinking about the issue of grpc and the environments. How would that explain the ln-service call working when running as a normal nodejs process and then running the same code, communicating with the same lnd node, but in the lambda container encounters the error? The first obvious difference I can think of is I have node v12 on my system but zeit/now runs in v10 as the highest option. I'm going to try running the way that has been working but with node v10.16 and see if that reproduces the error.

[alexbosworth]

Same issue I suppose, check for undefined instead of falsey

[bucko13]

Yep! That did it. Is it problematic then to have that check undefined as well? Do you want me to separate that out into a separate branch to put up for a PR or is this not something you think should be in the main branch?

[alexbosworth]

it occurs to me another strategy is to change the proto file to add the string hints, maybe that would work and avoid this divergence?

[alexbosworth]

here is a code example of how to signal strings on int64

https://github.com/lightningnetwork/lnd/pull/2352/files