Implement accepting dual-funded channels without contributing #3137

dunxen · 2024-06-20T11:02:30Z

We split this out from #2302 for easier review and to address the common non-public API parts of the V2 channel establishment implementation.

This will allow the holder to be an acceptor, but not initiator of V2 channels. We also don't expose an API for contributing to an inbound channel.

The functionality to initiate V2 channels and fund inbound channels forms part of #2302.

codecov-commenter · 2024-06-24T17:04:11Z

Codecov Report

Attention: Patch coverage is 19.21331% with 1068 lines in your changes missing coverage. Please review.

Project coverage is 88.66%. Comparing base (ca27a85) to head (2216120).
Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	5.66%	466 Missing ⚠️
lightning/src/ln/channelmanager.rs	21.75%	408 Missing and 2 partials ⚠️
lightning/src/ln/interactivetxs.rs	36.63%	191 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3137      +/-   ##
==========================================
- Coverage   89.63%   88.66%   -0.98%     
==========================================
  Files         126      126              
  Lines      102668   105124    +2456     
  Branches   102668   105124    +2456     
==========================================
+ Hits        92028    93205    +1177     
- Misses       7919     9261    +1342     
+ Partials     2721     2658      -63

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

optout21

Looks great, mostly localized code improvements suggested.

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/mod.rs

optout21 · 2024-06-26T12:42:52Z

As I see, the dual_funding cfg flag has been removed (not a problem)

optout21 · 2024-06-26T12:43:36Z

Looks to me that #2989 is in fact included in this PR (good!)

lightning/src/events/mod.rs

TheBlueMatt

Some initial comments, sorry this took so long to get back to.

lightning/src/events/mod.rs

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

TheBlueMatt · 2024-07-08T02:06:29Z

lightning/src/ln/channelmanager.rs

+
+						if chan.interactive_tx_signing_session.is_some() {
+							let monitor = try_chan_phase_entry!(self,
+								chan.commitment_signed_initial_v2(&msg, best_block, &self.signer_provider, &&logger), chan_phase_entry);


Ugh...So the spec changed the definition of commitment_signed to now also include the initial funding commitment tx signing? Even though it implies other things inside the interactive state machine? Is it too late to change this? This seems nuts.

Does this mean that we should support adding HTLCs prior to the initial commitment transaction?

The previous things it implies should really be looked at in the spec and changed there. We don't want to support adding HTLCs prior to initial commitment. So I really need to investigate what is going on with the spec and what might need to be fixed there.

TheBlueMatt · 2024-07-08T02:07:19Z

lightning/src/ln/channelmanager.rs

+						if chan.interactive_tx_signing_session.is_some() {
+							let monitor = try_chan_phase_entry!(self,
+								chan.commitment_signed_initial_v2(&msg, best_block, &self.signer_provider, &&logger), chan_phase_entry);
+							if let Ok(persist_status) = self.chain_monitor.watch_channel(chan.context.get_funding_txo().unwrap(), monitor) {


If the persist status is pending we need to handle the later stuff in monitor_updating_restored. Really the whole contents of the block here should be in monitor_updating_restored.

lightning/src/ln/channel.rs

dunxen

Thanks @TheBlueMatt, for review and some good points raised. I'll address these ASAP ❤️

dunxen · 2024-07-10T16:06:44Z

Still working on remaining initial feedback.

TheBlueMatt · 2024-07-15T15:51:54Z

No rush, let me know when you want another pass.

lightning/src/ln/interactivetxs.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/channel.rs

dunxen · 2024-09-03T14:05:39Z

I see there is still a lot of potential DRYing up to do here.

lightning/src/ln/channel.rs

TheBlueMatt

Few quick questions.

TheBlueMatt · 2024-09-04T19:11:46Z

lightning/src/ln/channel.rs

@@ -4480,6 +4759,105 @@ impl<SP: Deref> Channel<SP> where
 		Ok(())
 	}

+	pub fn commitment_signed_initial_v2<L: Deref>(


Shouldn't this be on OutboundChannelV2 since its basically the funding_signed equivalent?

Here we are just adding it for inbound V2 channels, but actually, eventually outbound will also need it once that's enabled (https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#the-commitment_signed-message), and I'll probably share the behaviour via InteractivelyFunded trait or something like that.

We'll want to handle it differently in that case, though, no? The initial commitment signed here is handled ~identical to funding_signed in OutboundV1Channel, which implies we need to DRY this up somewhat (by moving it to ChannelContext), but actually exposing it seems like something we should do on the type so that V1 and V2 work the same as each other as much as possible.

Moving this to Channel is a pretty substantial difference - we're now moving from the Outbound logic to the Channel/funded logic at a different point in the channel's lifecycle, which I'll be honest I don't really want to have to review.

lightning/src/ln/channel.rs

jkczyz · 2024-09-10T19:08:27Z

lightning/src/ln/channel.rs

+	pub fn funding_tx_constructed<L: Deref>(
+		&mut self, signing_session: &mut InteractiveTxSigningSession, logger: &L
+	) -> Result<(msgs::CommitmentSigned, Option<Event>), ChannelError>
+	where
+		L::Target: Logger
+	{
+		let (commitment_signed, funding_ready_for_sig_event) = match self.internal_funding_tx_constructed(
+			signing_session, logger,
+		) {
+			Ok(res) => res,
+			Err(err) => return Err(err),
+		};
+
+		Ok((commitment_signed, funding_ready_for_sig_event))
+	}


The entire method body can be replaced with:

self.internal_funding_tx_constructed(signing_session, logger)

So better to just drop this method and rename internal_funding_tx_constructed to funding_tx_constructed?

jkczyz · 2024-09-10T20:11:59Z

lightning/src/ln/channel.rs

@@ -8756,6 +9023,85 @@ fn get_initial_channel_type(config: &UserConfig, their_features: &InitFeatures)
 	ret
 }

+fn get_initial_counterparty_commitment_signature<SP:Deref, L: Deref>(
+	context: &mut ChannelContext<SP>, logger: &L


context doesn't need to be a &mut here.

jkczyz · 2024-09-10T20:18:02Z

lightning/src/ln/channel.rs

@@ -8756,6 +9023,85 @@ fn get_initial_channel_type(config: &UserConfig, their_features: &InitFeatures)
 	ret
 }

+fn get_initial_counterparty_commitment_signature<SP:Deref, L: Deref>(


Would it make sense to make this a method on ChannelContext?

Likewise for get_initial_commitment_signed. At least there is a get_funding_signed_msg there already.

jkczyz · 2024-09-10T20:26:58Z

lightning/src/ln/channel.rs

+			Ok(ecdsa.sign_counterparty_commitment(&counterparty_initial_commitment_tx, Vec::new(), Vec::new(), &context.secp_ctx)
+				.map_err(|_| ChannelError::Close(
+					(
+						"Failed to get signatures for new commitment_signed".to_owned(),
+						ClosureReason::HolderForceClosed { broadcasted_latest_txn: Some(false) },
+					)))?.0)


A little more idiomatic and readable to map rather than use ?.0 and re-wrap.

diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs index d9fe0c5dd..dfa87a319 100644 --- a/lightning/src/ln/channel.rs +++ b/lightning/src/ln/channel.rs @@ -9053,12 +9021,13 @@ where match context.holder_signer { // TODO (taproot|arik): move match into calling method for Taproot ChannelSignerType::Ecdsa(ref ecdsa) => { - Ok(ecdsa.sign_counterparty_commitment(&counterparty_initial_commitment_tx, Vec::new(), Vec::new(), &context.secp_ctx) + ecdsa.sign_counterparty_commitment(&counterparty_initial_commitment_tx, Vec::new(), Vec::new(), &context.secp_ctx) + .map(|(signature, _)| signature) .map_err(|_| ChannelError::Close( ( "Failed to get signatures for new commitment_signed".to_owned(), ClosureReason::HolderForceClosed { broadcasted_latest_txn: Some(false) }, - )))?.0) + ))) }, // TODO (taproot|arik) #[cfg(taproot)]

jkczyz · 2024-09-10T21:18:57Z

lightning/src/ln/channelmanager.rs

+	/// Handles a signed funding transaction generated by interactive transaction construction and
+	/// provided by the client.


Isn't really clear from the docs when a user would call this and where transaction comes from. Or at least the wording is confusing to me.

jkczyz · 2024-09-10T22:12:35Z

lightning/src/ln/channelmanager.rs

+					match chan_phase_entry.get_mut() {
+						ChannelPhase::UnfundedOutboundV2(chan) => {
+							chan.funding_tx_constructed(&mut signing_session, &self.logger)
+						},
+						ChannelPhase::UnfundedInboundV2(chan) => {
+							chan.funding_tx_constructed(&mut signing_session, &self.logger)
+						},
+						_ => Err(ChannelError::Warn(
+							"Got a tx_complete message with no interactive transaction construction expected or in-progress"
+							.into())),
+					}.and_then(|(commitment_signed, funding_ready_for_sig_event_opt)| {
+							let (channel_id, channel_phase) = chan_phase_entry.remove_entry();
+							match channel_phase {
+								ChannelPhase::UnfundedOutboundV2(chan) => {
+									chan.into_channel(signing_session)
+								},
+								ChannelPhase::UnfundedInboundV2(chan) => {
+									chan.into_channel(signing_session)
+								},
+								_ => {
+									debug_assert!(false); // It cannot be another variant as we are in the `Ok` branch of the above match.
+									Err(ChannelError::Warn(
+										"Got a tx_complete message with no interactive transaction construction expected or in-progress"
+											.into()))
+								}
+							}.map(|channel| (channel_id, channel, funding_ready_for_sig_event_opt, commitment_signed))
+						}).map(|(channel_id, channel, funding_ready_for_sig_event_opt, commitment_signed)| {
+							peer_state.channel_by_id.insert(channel_id, ChannelPhase::Funded(channel));
+							if let Some(funding_ready_for_sig_event) = funding_ready_for_sig_event_opt {
+								let mut pending_events = self.pending_events.lock().unwrap();
+								pending_events.push_back((funding_ready_for_sig_event, None));
+							}
+							peer_state.pending_msg_events.push(events::MessageSendEvent::UpdateHTLCs {
+								node_id: counterparty_node_id,
+								updates: CommitmentUpdate {
+									commitment_signed,
+									update_add_htlcs: vec![],
+									update_fulfill_htlcs: vec![],
+									update_fail_htlcs: vec![],
+									update_fail_malformed_htlcs: vec![],
+									update_fee: None,
+								},
+							});
+						}).map_err(|err| MsgHandleErrInternal::send_err_msg_no_close(format!("{}", err), msg.channel_id))


When possible, it's best to avoid side-effects inside map and and_then calls. It would make the code easier to follow and less indented. Consider the following:

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs index b23bd08ff..c2e67287a 100644 --- a/lightning/src/ln/channelmanager.rs +++ b/lightning/src/ln/channelmanager.rs @@ -7955,7 +7955,7 @@ where }; if let Some(mut signing_session) = signing_session_opt { let funding_txid = signing_session.unsigned_tx.txid(); - match chan_phase_entry.get_mut() { + let (commitment_signed, funding_ready_for_sig_event_opt) = match chan_phase_entry.get_mut() { ChannelPhase::UnfundedOutboundV2(chan) => { chan.funding_tx_constructed(&mut signing_session, &self.logger) }, @@ -7965,45 +7965,39 @@ where _ => Err(ChannelError::Warn( "Got a tx_complete message with no interactive transaction construction expected or in-progress" .into())), - }.and_then(|(commitment_signed, funding_ready_for_sig_event_opt)| { - let (channel_id, channel_phase) = chan_phase_entry.remove_entry(); - match channel_phase { - ChannelPhase::UnfundedOutboundV2(chan) => { - chan.into_channel(signing_session) - }, - ChannelPhase::UnfundedInboundV2(chan) => { - chan.into_channel(signing_session) - }, - _ => { - debug_assert!(false); // It cannot be another variant as we are in the `Ok` branch of the above match. - Err(ChannelError::Warn( - "Got a tx_complete message with no interactive transaction construction expected or in-progress" - .into())) - } - }.map(|channel| (channel_id, channel, funding_ready_for_sig_event_opt, commitment_signed)) - }).map(|(channel_id, mut channel, funding_ready_for_sig_event_opt, commitment_signed)| { - channel.set_next_funding_txid(&funding_txid); - peer_state.channel_by_id.insert(channel_id, ChannelPhase::Funded(channel)); - if let Some(funding_ready_for_sig_event) = funding_ready_for_sig_event_opt { - let mut pending_events = self.pending_events.lock().unwrap(); - pending_events.push_back((funding_ready_for_sig_event, None)); - } - peer_state.pending_msg_events.push(events::MessageSendEvent::UpdateHTLCs { - node_id: counterparty_node_id, - updates: CommitmentUpdate { - commitment_signed, - update_add_htlcs: vec![], - update_fulfill_htlcs: vec![], - update_fail_htlcs: vec![], - update_fail_malformed_htlcs: vec![], - update_fee: None, - }, - }); - }).map_err(|err| MsgHandleErrInternal::send_err_msg_no_close(format!("{}", err), msg.channel_id)) - } else { - // We're not in a signing session yet so we don't need to do anything else. - Ok(()) + }.map_err(|err| MsgHandleErrInternal::send_err_msg_no_close(format!("{}", err), msg.channel_id))?; + + let (channel_id, channel_phase) = chan_phase_entry.remove_entry(); + let mut channel = match channel_phase { + ChannelPhase::UnfundedOutboundV2(chan) => chan.into_channel(signing_session), + ChannelPhase::UnfundedInboundV2(chan) => chan.into_channel(signing_session), + _ => { + debug_assert!(false); // It cannot be another variant as we are in the `Ok` branch of the above match. + Err(ChannelError::Warn( + "Got a tx_complete message with no interactive transaction construction expected or in-progress" + .into())) + }, + }.map_err(|err| MsgHandleErrInternal::send_err_msg_no_close(format!("{}", err), msg.channel_id))?; + + channel.set_next_funding_txid(&funding_txid); + peer_state.channel_by_id.insert(channel_id, ChannelPhase::Funded(channel)); + if let Some(funding_ready_for_sig_event) = funding_ready_for_sig_event_opt { + let mut pending_events = self.pending_events.lock().unwrap(); + pending_events.push_back((funding_ready_for_sig_event, None)); + } + peer_state.pending_msg_events.push(events::MessageSendEvent::UpdateHTLCs { + node_id: counterparty_node_id, + updates: CommitmentUpdate { + commitment_signed, + update_add_htlcs: vec![], + update_fulfill_htlcs: vec![], + update_fail_htlcs: vec![], + update_fail_malformed_htlcs: vec![], + update_fee: None, + }, + }); } + Ok(()) }, hash_map::Entry::Vacant(_) => { Err(MsgHandleErrInternal::send_err_msg_no_close(format!("Got a message for a channel from the wrong node! No such channel for the passed counterparty_node_id {}", counterparty_node_id), msg.channel_id))

jkczyz · 2024-09-10T22:16:37Z

lightning/src/ln/channel.rs

@@ -9530,7 +9542,8 @@ impl<SP: Deref> Writeable for Channel<SP> where SP::Target: SignerProvider {
 			(47, next_holder_commitment_point, option),
 			(49, self.context.local_initiated_shutdown, option), // Added in 0.0.122
 			(51, is_manual_broadcast, option), // Added in 0.0.124
-			(53, funding_tx_broadcast_safe_event_emitted, option) // Added in 0.0.124
+			(53, funding_tx_broadcast_safe_event_emitted, option), // Added in 0.0.124
+			(55, self.context.next_funding_txid, option) // Added in 0.0.125


Need to add this to the ReadableArgs implementation as discussed offline.

optout21 · 2024-09-11T21:50:08Z

lightning/src/ln/mod.rs

@@ -96,7 +96,7 @@ mod async_signer_tests;
 #[cfg(test)]
 #[allow(unused_mut)]
 mod offers_tests;
-#[allow(dead_code)] // TODO(dual_funding): Exchange for dual_funding cfg
+#[allow(dead_code)] // TODO(splicing): Exchange for splicing cfg


I think the dead_code exception no longer needed. This change seems to be search/and/replace false positive.

TheBlueMatt · 2024-09-17T19:10:02Z

Needs rebase now :(

dunxen · 2024-09-18T10:19:51Z

Needs rebase now :(

Sorry, catching up on everything now! Been mostly offline for a week.

dunxen · 2024-09-18T11:05:29Z

Just rebased for now while I'm still addressing past week's feedback.

We'll only gate public API related to contributing toward an inbound or opening a dual funded channel.

Here we add the `interactive_tx_constructor` field to the `Channel`, `OutboundV2Channel`, and `InboundV2Channel` structs.

dunxen added the Dual-funding label Jun 20, 2024

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch 3 times, most recently from b981cd7 to 0caf60e Compare June 20, 2024 16:14

dunxen marked this pull request as ready for review June 20, 2024 16:27

dunxen mentioned this pull request Jun 20, 2024

Implement V2 channel establishment #2302

Draft

4 tasks

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 0caf60e to 44821af Compare June 24, 2024 16:55

optout21 requested changes Jun 26, 2024

View reviewed changes

optout21 mentioned this pull request Jun 27, 2024

Interactive TX negotiation tracks shared outputs #2989

Merged

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch 4 times, most recently from 0db700b to 7dceedd Compare July 3, 2024 09:44

dunxen requested review from optout21 and TheBlueMatt and removed request for optout21 July 3, 2024 09:51

optout21 previously approved these changes Jul 3, 2024

View reviewed changes

lightning/src/events/mod.rs Outdated Show resolved Hide resolved

dunxen requested a review from jkczyz July 4, 2024 15:02

TheBlueMatt reviewed Jul 8, 2024

View reviewed changes

dunxen commented Jul 8, 2024

View reviewed changes

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 7dceedd to 64c35f4 Compare July 10, 2024 16:05

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 64c35f4 to a46da5a Compare July 11, 2024 14:55

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch 2 times, most recently from 0613f64 to 93896c4 Compare July 16, 2024 10:36

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 6b7c977 to 5febfc9 Compare August 29, 2024 20:02

This was referenced Aug 30, 2024

Support RBF for interactively constructed transactions #3281

Open

Dual-funded channels and Splicing Project Tracking #1621

Open

jkczyz reviewed Aug 30, 2024

View reviewed changes

lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved

lightning/src/ln/interactivetxs.rs Outdated Show resolved Hide resolved

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 5febfc9 to 8e70429 Compare September 3, 2024 14:05

jkczyz reviewed Sep 3, 2024

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

TheBlueMatt reviewed Sep 4, 2024

View reviewed changes

This was referenced Sep 5, 2024

[Splicing] Add splicing compile feature flag #3294

Closed

[Splicing] Support shared signature in InteractiveTransaction #3295

Open

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 8e70429 to fba77f2 Compare September 5, 2024 15:47

optout21 mentioned this pull request Sep 6, 2024

Basic Splicing #3298

Open

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from fba77f2 to 9b46d1f Compare September 6, 2024 11:23

jkczyz reviewed Sep 10, 2024

View reviewed changes

optout21 reviewed Sep 11, 2024

View reviewed changes

dunxen dismissed optout21’s stale review via 9b46d1f September 17, 2024 14:06

Add dual-funding spec links

ce2ccc3

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 9b46d1f to 2b65e1f Compare September 18, 2024 11:04

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 2b65e1f to 6dc0b7c Compare September 19, 2024 22:27

dunxen added 7 commits September 20, 2024 07:32

Remove dual_funding cfg attributes

fc1d8f9

We'll only gate public API related to contributing toward an inbound or opening a dual funded channel.

Add interactive tx constructor to all V2-related channel structs

6e22400

Here we add the `interactive_tx_constructor` field to the `Channel`, `OutboundV2Channel`, and `InboundV2Channel` structs.

Implement support for accepting V2 channels

652b7ae

Handle initial commitment_signed for V2 channels

a147e3a

Handle re-establishment next_funding_txid

cc2c3a2

Add option_dual_fund feature

b21d790

Temporarily allow some unused dual-funding code

2216120

dunxen force-pushed the 2024-06-non-public-API-v2-channels branch from 6dc0b7c to 2216120 Compare September 19, 2024 22:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement accepting dual-funded channels without contributing #3137

Implement accepting dual-funded channels without contributing #3137

dunxen commented Jun 20, 2024

codecov-commenter commented Jun 24, 2024 •

edited by codecov bot

Loading

optout21 left a comment •

edited

Loading

optout21 commented Jun 26, 2024

optout21 commented Jun 26, 2024

TheBlueMatt left a comment

TheBlueMatt Jul 8, 2024

dunxen Jul 9, 2024 •

edited

Loading

TheBlueMatt Jul 8, 2024

dunxen left a comment

dunxen commented Jul 10, 2024

TheBlueMatt commented Jul 15, 2024

dunxen commented Sep 3, 2024

TheBlueMatt left a comment

TheBlueMatt Sep 4, 2024

dunxen Sep 5, 2024

TheBlueMatt Sep 9, 2024

jkczyz Sep 10, 2024

jkczyz Sep 10, 2024

jkczyz Sep 10, 2024

jkczyz Sep 10, 2024

jkczyz Sep 10, 2024

jkczyz Sep 10, 2024

jkczyz Sep 10, 2024

optout21 Sep 11, 2024

TheBlueMatt commented Sep 17, 2024

dunxen commented Sep 18, 2024

dunxen commented Sep 18, 2024

		/// Handles a signed funding transaction generated by interactive transaction construction and
		/// provided by the client.

Implement accepting dual-funded channels without contributing #3137

Are you sure you want to change the base?

Implement accepting dual-funded channels without contributing #3137

Conversation

dunxen commented Jun 20, 2024

codecov-commenter commented Jun 24, 2024 • edited by codecov bot Loading

Codecov Report

optout21 left a comment • edited Loading

Choose a reason for hiding this comment

optout21 commented Jun 26, 2024

optout21 commented Jun 26, 2024

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunxen Jul 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunxen left a comment

Choose a reason for hiding this comment

dunxen commented Jul 10, 2024

TheBlueMatt commented Jul 15, 2024

dunxen commented Sep 3, 2024

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt commented Sep 17, 2024

dunxen commented Sep 18, 2024

dunxen commented Sep 18, 2024

codecov-commenter commented Jun 24, 2024 •

edited by codecov bot

Loading

optout21 left a comment •

edited

Loading

dunxen Jul 9, 2024 •

edited

Loading