breez / breez-sdk-greenlight

MIT License
241 stars 42 forks source link

greenlight compilation error #1010

Closed vincenzopalazzo closed 4 months ago

vincenzopalazzo commented 4 months ago

Trying to debug my green wallet with lightning and I would like to use the sdk-cli. However, I get the following compilation error

➜  sdk-cli git:(main) ✗ cargo run
   Compiling gl-client v0.2.0 (https://github.com/Blockstream/greenlight.git?rev=e38a37613da7558c853f24be700c193f194a6bc9#e38a3761)
error[E0412]: cannot find type `DelexpiredinvoiceRequest` in module `cln`
    --> /home/vincent/.cargo/git/checkouts/greenlight-e41cf58dbd255ee0/e38a376/libs/gl-client/src/signer/model/mod.rs:41:28
     |
41   |     DelExpiredInvoice(cln::DelexpiredinvoiceRequest),
     |                            ^^^^^^^^^^^^^^^^^^^^^^^^ help: a struct with a similar name exists: `DelinvoiceRequest`
     |
    ::: /home/vincent/github/work/breez-sdk/tools/sdk-cli/target/debug/build/cln-grpc-7a25774ebd2ceb74/out/cln.rs:1800:1
     |
1800 | pub struct DelinvoiceRequest {
     | ---------------------------- similarly named struct `DelinvoiceRequest` defined here

error[E0433]: failed to resolve: use of undeclared type `DelexpiredinvoiceRequest`
  --> /home/vincent/.cargo/git/checkouts/greenlight-e41cf58dbd255ee0/e38a376/libs/gl-client/src/signer/model/cln.rs:27:62
   |
27 |     "/cln.Node/DelExpiredInvoice" => Request::DelExpiredInvoice(DelexpiredinvoiceRequest::decode(p)?),
   |                                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
   |                                                                 |
   |                                                                 use of undeclared type `DelexpiredinvoiceRequest`
   |                                                                 help: a struct with a similar name exists: `DelinvoiceRequest`

error[E0599]: no method named `bolt11` found for reference `&cln_grpc::pb::PreapproveinvoiceRequest` in the current scope
   --> /home/vincent/.cargo/git/checkouts/greenlight-e41cf58dbd255ee0/e38a376/libs/gl-client/src/signer/resolve.rs:102:40
    |
102 |                     l.invstring.0 == r.bolt11().as_bytes()
    |                                        ^^^^^^-- help: remove the arguments
    |                                        |
    |                                        field, not a method

Some errors have detailed explanations: E0412, E0433, E0599.
For more information about an error, try `rustc --explain E0412`.
The following warnings were emitted during compilation:

warning: gl-client@0.2.0: Using default NOBODY cert.
warning: gl-client@0.2.0: Set "GL_CUSTOM_NOBODY_KEY" and "GL_CUSTOM_NOBODY_CERT" to use a custom cert.

Probably is it a greenlight issue but idk how it is import inside the SDK-cli, so I will start reporting the problem from here

roeierez commented 4 months ago

Thanks @vincenzopalazzo Is it on the main sdk branch? We recently update the gl-client dependency.

vincenzopalazzo commented 4 months ago

@roeierez I did just a git clone, so I assume it was main

roeierez commented 4 months ago

I just ran the cli on master and it works for me.

From the compiler log: Compiling gl-client v0.2.0 (https://github.com/Blockstream/greenlight.git?rev=e38a37613da7558c853f24be700c193f194a6bc9#e38a3761)

I see we also use the same revision. I will try to clone a new repo.

roeierez commented 4 months ago

Also cloned a new repo and seems to work. Could it be that the cln-grpc dependency is not updated in your run? What is the version of this dependency in cargo.lock ?

vincenzopalazzo commented 4 months ago

MH you are right now I clone again inside a tmp dir and it is working

Probably I did not clone the repo but I did a git pull, testing right now.

Ok on a fresh clone I have no error, but on already cloned repo after git pull I get the same error

but I am on the same commit 5d022f719308531da0ebb55098c3cee031b5c7af

Strange

vincenzopalazzo commented 4 months ago

@roeierez I reproduce the same error in the fresh clone by running cargo install --path .

Are you able to reproduce?

roeierez commented 4 months ago

I also get this error now when running cargo install --path . But I don't get this error if running cargo buildor cargo run

ok300 commented 4 months ago

We've seen this in the past:

The root cause is described in detail here.

It essentially happens because most libraries use loose semantic versioning ranges for their dependencies. When they release, the release is tested with a specific set of dependency versions. However, soon after this release, a dependency could release a newer version that fits in the original library's Cargo.toml semantic versioning range. This means new apps trying to integrate this library will use the newest dependency version (e.g. dependency of library), which may break the library itself because it was not tested with that version.

The fix has been to find these problematic transitive dependencies and pin them to a valid working version.

(The reason it behaves differently when you git pull vs when you setup a fresh project is, on git pull, cargo will try to use the existing Cargo.lock, which may have an older working transitive dependency version. On a fresh new setup, cargo always tries to fetch the newest transitive dependency.)

IMO the goal now is to find out which dependency changed since the latest working release and now.

Looking into it, will post an update when I find something.

(P.S. @roeierez this is the reason for the proposed PR https://github.com/breez/breez-sdk/pull/971)

ok300 commented 4 months ago

@vincenzopalazzo this is being addressed in #1014 .

Until that's reviewed and merged, can you please try to add

# Pin problematic transitive dependencies
cln-grpc = "=0.1.8"

to your Cargo.toml then try again?

ok300 commented 4 months ago

@vincenzopalazzo the issue is fixed now. Please do cargo clean, then recompiling the project should work.