[karliatto]

open-channel returned as soon as the open was initiated, so scripts had to poll list-channels to learn whether the counterparty accepted or rejected the channel.

With --wait, the CLI subscribes to the event stream before calling open_channel, since the stream is live-only, and waits for a ChannelStateChanged event for the returned user_channel_id. Pending (or Ready, if Pending was missed) counts as success and prints the channel_id and funding_txo. OpenFailed or Closed counts as failure and prints the reason from the server. It does not wait for the funding transaction to confirm.

--wait-timeout <SECS> bounds the wait. On timeout the CLI prints the current entry for the channel from list_channels, if there is one. Exit codes are 0 for pending, 1 for a request or event stream error, 2 for a failed open and 3 for a timeout, matching pay --wait.

For example when opening a channel for 100.000 sats when 200.000 is the minimum required by the counterpart node the command open-channel will finish and just replied:

{
  "user_channel_id": "<user-channel-id>"
}

But if the user looks for the channel using list-channels the user cannot see anything about that channel. In order to know what happened the user has to actually look at the logs of the server. Or there might be other way I did not find.

With the new --wait when the same situation as before happens, it gives the user information about the failed channel open and the reason.

Channel open initiated: <user-channel-id> (waiting for the counterparty)
Channel open <user-channel-id> failed: Channel closed because counterparty force-closed with message: chan size of 0.00100000 BTC is below min chan size of 0.00200000 BTC

And when the opening is successful it gives:

Channel open initiated: <user-channel-id> (waiting for the counterparty)
{
  "channel_id": "<channel-id>",
  "funding_txo": "<funding-tx-id>",
  "user_channel_id": "<user-channel-id>"
}

[ldk-reviews-bot]

I've assigned @benthecarman as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[benthecarman]

The wait logic here is mostly the same as pay_wait.rs just copied. Could we pull the common parts into a shared module before this lands? pay --wait and open-channel --wait are the first two, and close-channel or splice will likely want --wait too. I'd rather the next one doesn't become a third copy.

[karliatto]

The wait logic here is mostly the same as pay_wait.rs just copied. Could we pull the common parts into a shared module before this lands? pay --wait and open-channel --wait are the first two, and close-channel or splice will likely want --wait too. I'd rather the next one doesn't become a third copy.

Thanks for the comment, that makes a lot of sense. I added new commit ce9d501 with the common parts in ldk-server-cli/src/event_wait.rs. Let me know what you think.

[benthecarman]

you do this as a refactor commit before the open-channel changes

[Anyitechs]

I see this was introduced in pay_wait.rs but not sure we need the unwrap() here? Given that the handle_error() function never returns. Same as below and elsewhere

[karliatto]

Without the unwrap() it fails to compile, since map_err keeps the Result and only changes the error type to !:

expected `&mut GrpcStream<EventEnvelope>`, found `&mut Result<GrpcStream<_>, !>`

Maybe changing it to something like below would read better:

let mut events = client.subscribe_events().await.unwrap_or_else(|e| handle_error(e));

Happy to apply it here and in pay_wait.rs, if that sounds good.

[Anyitechs]

Maybe changing it to something like below would read better:

let mut events = client.subscribe_events().await.unwrap_or_else(|e| handle_error(e));

Yes, it does. Thank you!

[karliatto]

I added the changes to it's corresponding commits:

8e21bcf#diff-d29e74cfebaf01882098a3e9ea4a9229d8e7766881d0cfca168d13e68d93236aL49
d2b4635#diff-fb260124cb53a088a5ac045c42477fb33b7230d3bf4d0dfa8edc00d9f85bb84aR32

[karliatto]

you do this as a refactor commit before the open-channel changes

Sure I changed so the refactor commit where pay_win uses the new event_wait is in the first commit and then implement the new open_channel_wait.

[benthecarman]

Could we add e2e tests for --wait? Both cases should work with the current harness:

• Success: the same setup as open_channel_via_cli, with --wait added. Assert exit code 0 and that the output has channel_id and funding_txo.
• Rejection: don't fund server_b. ldk-node rejects inbound anchor channels when it lacks the on-chain reserve, so the open should fail with "Channel request rejected". Assert exit code 2 and that the reason is in the output.

run_cli_raw panics on any non-zero exit, so the rejection test needs a small helper that returns the raw Output. run_cli_raw could then call it.

[benthecarman]

Could success and failure both print the ChannelStateChanged event to stdout?

At the moment success prints a hand-built json! object, and failure prints nothing to stdout, only a message on stderr. A script that sees exit code 2 has to parse the stderr text to learn why the open failed. pay --wait prints a GetPaymentDetailsResponse for success, failure and timeout, so scripts can always parse stdout the same way.

We can't do quite the same here, because a channel that failed to open is already gone from list_channels. But the event works for both resolved outcomes:

WaitOutcome::Matched(Outcome::Pending(event)) => print_response(&event),
WaitOutcome::Matched(Outcome::Failed(event)) => {
	// keep the existing stderr message
	...
	print_response(&event);
	std::process::exit(EXIT_WAIT_FAILED);
},

On success this still includes user_channel_id, channel_id and funding_txo, and adds state and counterparty_node_id. On failure, scripts can read reason.kind instead of matching on message text. The serde_json::json import can go after this change. Keeping the Channel from list_channels on timeout is fine, since pay also queries the current state there.