BOLT 12 Offers utilities #2578

jkczyz · 2023-09-14T22:44:29Z

Add utility methods to ChannelManager for:

creating OfferBuilder such that derived keys are used for the signing pubkey,
creating RefundBuilder such that derived keys are used for the payer id, and
sending an InvoiceRequest for an Offer such that derived keys are used for the payer id

When the ChannelManager is the payer (i.e., when creating Refund and InvoiceRequest), a PaymentId is required and used for tracking the outbound payment once the Bolt12Invoice is received.

One-hop blinded paths are used throughout until multi-hop blinded paths are supported.

Offer message handling and sending a Bolt12Invoice for a Refund such that derived keys are used for the signing pubkey are in #2039, which is based on this PR.

TheBlueMatt · 2023-09-17T02:18:02Z

lightning/src/onion_message/messenger.rs

+	/// The message contents to send in an [`OnionMessage`].
+	///
+	/// [`OnionMessage`]: crate::ln::msgs::OnionMessage
+	pub contents: T,


Hmm, if we leave a totally unbounded type that's gonna be a problem for bindings. Can we bound this by CustomOnionMessageContents (or if we need a general bound we could create an OnionMessageContents trait that we impl for BOLT12 messages as well)?

We'll need a more general bound since OffersMessage is used, too.

TheBlueMatt · 2023-09-17T02:27:38Z

lightning/src/ln/channelmanager.rs

+	/// [`InvoiceRequest`]: crate::offers::invoice_request::InvoiceRequest
+	/// [`InvoiceRequestBuilder`]: crate::offers::invoice_request::InvoiceRequestBuilder
+	/// [`Bolt12Invoice`]: crate::offers::invoice::Bolt12Invoice
+	pub fn request_invoice(


Does this need to be pub? I'm not sure what the use is for this outside of simply paying an offer, which is presumably a different method.

Ah, this is the "paying for an offer" method. I guess that I can rename it to be more user- rather than implementation-focused.

TheBlueMatt · 2023-09-18T19:36:59Z

lightning/src/onion_message/packet.rs

@@ -118,6 +118,13 @@ pub enum OnionMessageContents<T: CustomOnionMessageContents> {
 	Custom(T),
 }

+/// A type used within a variant of [`OnionMessageContents`].
+pub trait OnionMessageContentsType {}


Rather than an empty trait, should we just rename CustomOnionMessageContents to OnionMessageContents and impl it for Bolt12/etc? Its already basically what we want - extends Write and has a tlv_type.

Hmmm... we already have an OnionMessageContents enum.

Oh, then lets use that in PendingOnionMessage instead of a generic type T?

It also seems arbitrary that a custom message handler isn't allowed to send BOLT12 messages.

But we don't want a BOLT 12 handler to be able to send arbitrary ones. A custom handler can alway have their type wrap OffersMessage in a variant.

I mean...why not? We could also drop OnionMessageContents or make it priv, and replace most usages with a trait.

Discussed offline and made the following changes:

Renamed OnionMessageContents to ParsedOnionMessageContents and gave it pub(super) visibility

Renamed CustomOnionMessageContents to OnionMessageContents and used it as a trait bound on most methods

Changed Payload to hold T instead of ParsedOnionMessageContents<T> where T: OnionMessageContents

Implemented OnionMessageContents for OffersMessage and ParsedOnionMessageContents. The latter is needed so that arbitrary Payload contents can be read and specific contents can be written

codecov-commenter · 2023-09-19T20:46:51Z

Codecov Report

Attention: 91 lines in your changes are missing coverage. Please review.

Comparison is base (0357caf) 89.04% compared to head (905028b) 88.96%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2578      +/-   ##
==========================================
- Coverage   89.04%   88.96%   -0.09%     
==========================================
  Files         112      112              
  Lines       87527    87632     +105     
  Branches    87527    87632     +105     
==========================================
+ Hits        77942    77963      +21     
- Misses       7345     7435      +90     
+ Partials     2240     2234       -6

Files	Coverage Δ
lightning/src/events/mod.rs	`28.97% <ø> (-4.86%)`	⬇️
lightning/src/ln/msgs.rs	`76.81% <ø> (ø)`
lightning/src/offers/offer.rs	`94.65% <100.00%> (+0.01%)`	⬆️
lightning/src/offers/parse.rs	`92.30% <ø> (ø)`
lightning/src/offers/refund.rs	`93.67% <100.00%> (+0.02%)`	⬆️
lightning/src/onion_message/functional_tests.rs	`96.95% <100.00%> (+0.07%)`	⬆️
lightning/src/routing/router.rs	`94.07% <ø> (ø)`
lightning/src/ln/outbound_payment.rs	`87.69% <90.32%> (+0.16%)`	⬆️
lightning/src/ln/peer_handler.rs	`58.79% <25.00%> (-0.10%)`	⬇️
lightning/src/blinded_path/mod.rs	`70.14% <33.33%> (-5.66%)`	⬇️
... and 4 more

... and 7 files with indirect coverage changes

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

valentinewallace

Initial look, just nits

valentinewallace · 2023-09-19T20:16:39Z

fuzz/src/onion_message.rs

@@ -208,19 +211,6 @@ mod tests {

 	#[test]
 	fn test_no_onion_message_breakage() {
-		let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


I don't mind too much, but why remove this?

Restored it but now the test needs to check against InvalidFirstHop, which I'm not sure if that is intended?

Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

Will reexamine this but want to get the other changes pushed for now.

Sure, I'd also be fine with saving this for follow-up if you want to note it in #1970.

Ok, other than the introduction node being wrong, when hardcoding a fix I'm also seeing this logging:

Received an onion message with path_id Some([]) and a reply_path

Instead of the expected:

Received an onion message with path_id None and a reply_path

But I don't understand how my change would affect the path_id. Any ideas?

Oh, nevermind on this. That was just because I had been building using some unpublished commits instead of during the rebase. 🤦‍♂️

Opened #2671

lightning/src/blinded_path/mod.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/msgs.rs

lightning/src/ln/channelmanager.rs

lightning/src/blinded_path/mod.rs

lightning/src/ln/channelmanager.rs

jkczyz · 2023-10-11T14:37:54Z

Rebased as there were a lot of merge conflicts from the last release.

lightning/src/onion_message/messenger.rs

valentinewallace · 2023-10-12T21:28:25Z

fuzz/src/onion_message.rs

@@ -208,19 +211,6 @@ mod tests {

 	#[test]
 	fn test_no_onion_message_breakage() {
-		let one_hop_om = "020000000000000000000000000000000000000000000000000000000000000e01055600020000000000000000000000000000000000000000000000000000000000000e01ae0276020000000000000000000000000000000000000000000000000000000000000002020000000000000000000000000000000000000000000000000000000000000e0101022a0000000000000000000000000000014551231950b75fc4402da1732fc9bebf00109500000000000000000000000000000004106d000000000000000000000000000000fd1092202a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005600000000000000000000000000000000000000000000000000000000000000";


Mm that shouldn't be intended. It looks like that's because the first-hop peer in the reply path isn't connected.

lightning/src/ln/channelmanager.rs

lightning/src/onion_message/offers.rs

jkczyz

Need to look into addressing the fuzz test comment still.

lightning/src/ln/channelmanager.rs

lightning/src/onion_message/offers.rs

TheBlueMatt · 2023-10-15T15:29:24Z

I think this LGTM, I guess its now based on #2662, but once that lands feel free to squash.

TheBlueMatt · 2023-10-15T19:56:37Z

There's probably gonna be some conflicts between this and #2599

TheBlueMatt

LGTM, some tiny nits, feel free to squash.

lightning/src/onion_message/messenger.rs

TheBlueMatt · 2023-10-18T17:52:12Z

lightning/src/ln/channelmanager.rs

+
+		let builder = RefundBuilder::deriving_payer_id(
+			description, node_id, expanded_key, entropy, secp_ctx, amount_msats, payment_id
+		)?


Pretty awkward to return a full huge enum just if the user provided an amount > MAX_VALUE_MSAT. Can we check it first and unwrap the builder? Then we don't have to add a dup payment id to Bolt12 errors, which feels wrong.

Wouldn't we still need two different errors? One for the amount and one for duplicate payment id?

If we are fine just using () then an explicit check isn't needed, as we can just use map_err on builder result.

I mean we can almost just panic if the amount is too high, but I think its fine to tell users "we return an error if you duplicate the payment id or the amount is greater than max-amount". Users can figure out if the amount isnt invalid and just assume the payment id is duplicative, basically.

I'm going to leave this as-is. We have a similar problem in pay_for_offer only there are many more ways the builder can fail there.

TheBlueMatt · 2023-10-18T17:54:34Z

lightning/src/ln/channelmanager.rs

@@ -1216,6 +1223,8 @@ where
 	event_persist_notifier: Notifier,
 	needs_persist_flag: AtomicBool,

+	pending_offers_messages: Mutex<Vec<PendingOnionMessage<OffersMessage>>>,


Since this is unused in this PR can we move this commit to the next PR? Maybe the pay_for_offer impl too.

Yeah, this is used in pay_for_offer, so will need to move both.

Moved these to #2039.

lightning/src/ln/channelmanager.rs

TheBlueMatt · 2023-10-18T17:58:49Z

lightning/src/ln/channelmanager.rs

+			.path(path);
+
+		self.pending_outbound_payments
+			.add_new_awaiting_invoice(payment_id, retry_strategy, max_total_routing_fee_msat)


I was assuming we'd min them, but honestly I'm fine with either version (as-is or with a min against the ticks).

TheBlueMatt · 2023-10-18T18:02:18Z

lightning/src/onion_message/messenger.rs

@@ -691,6 +731,8 @@ fn packet_payloads_and_keys<T: CustomOnionMessageContents, S: secp256k1::Signing
 						next_node_id: intro_node_id,
 						next_blinding_override: Some(blinding_pt),
 					})), control_tlvs_ss));
+				} else {
+					prev_control_tlvs_ss = Some(control_tlvs_ss);


Tests seem to pass fine with this line omitted (and it looks like this is init'd in the else in the below if).

Yeah, looks like it is no longer needed after rebasing as the new code was added in 7c1726b.

jkczyz · 2023-10-18T19:47:54Z

Speaking of timeouts, we should check if the payment has timed out per the AwaitingInvoice::retry_stragety (assuming its a time-based one) in the timer tick too.

Discussed offline. It would be better to keep the retry strategy separate from when to expire waiting for an invoice.

TheBlueMatt · 2023-10-18T20:15:37Z

Only comment left form my end is #2578 (comment), which you can fix or not, but either way lets squash and I'll ack :)

TheBlueMatt · 2023-10-18T21:13:10Z

Sorry needs a small-ish rebase after #2599.

OnionMessageProvider is a super-trait of OnionMessageHandler, but they don't need to be used separately. Additionally, the former is misplaced in the events module. Remove OnionMessageProvider and add it's only method, next_onion_message_for_peer, into OnionMessageHandler.

OnionMessenger can send onion message responses from its handlers using respond_with_onion_message, which finds a path to the destination and enqueues the response for sending. Generalize this as it can be used not only for responses but for initial sends as well.

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace

LGTM after rebase

lightning/src/ln/channelmanager.rs

lightning/src/onion_message/messenger.rs

Rename CustomOnionMessageContents to OnionMessageContents and use it as a trait bound on messages passed to OnionMessenger methods. This allows using the trait in an upcoming commit as a bound on the contents of PendingOnionMessage. Also, make ParsedOnionMessageContent implement OnionMessageContents so that Payload can be bounded by OnionMessageContents directly, but used when either reading a ParsedOnionMessageContent or writing a specific type of OnionMessageContents (e.g., OffersMessage).

When constructing onion messages to send initially (opposed to replying to one from a handler), the user must construct an OnionMessagePath first before calling OnionMessener::send_onion_message. Additionally, having a reference to OnionMessener isn't always desirable. For instance, in an upcoming commit, ChannelManager will implement OffersMessageHandler, which OnionMessenger needs a reference to. If ChannelManager had a reference to OnionMessenger, too, there would be a dependency cycle. Instead, modify OffersMessageHandler and CustomOnionMessageHandler's interfaces to include a method for releasing pending onion messages. That way, ChannelManager may, for instance, construct and enqueue an InvoiceRequest for sending without needing a reference to OnionMessenger. Additionally, OnionMessenger has responsibility for path finding just as it does when replying to messages from a handler. It performs this when extracting messages from the handlers before returning the next message to send to a peer.

This allows for specifying the introduction node as the message recipient.

PendingOutboundPayment::AwaitingInvoice counts the number of timer ticks that have passed awaiting a Bolt12Invoice for an InvoiceRequest. When a constant INVOICE_REQUEST_TIMEOUT_TICKS has passed, the payment is forgotten. However, this mechanism is insufficient for the Refund scenario, where the Refund's expiration should be used instead. Change AwaitingInvoice to store an absolute expiry instead. When removing stale payments, pass the `SystemTime` in `std` and the highest block time minus two hours in `no-std`.

Add utility functions to ChannelManager for creating OfferBuilder, and RefundBuilder such that derived keys are used for the signing pubkey and payer id, respectively. This allows for stateless verification of any InvoiceRequest and Invoice messages. Later, blinded paths can be included in the returned builders. Also tracks future payments using the given PaymentId such that the corresponding Invoice is paid only once.

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

For consistency with other functions and doc cleanliness.

jkczyz · 2023-10-18T23:39:08Z

Sorry needs a small-ish rebase after #2599.

Rebased. Needed to expose ParsedOnionMessageContents because of this.

TheBlueMatt · 2023-10-19T02:41:34Z

lightning/src/ln/channelmanager.rs

+	/// Creates a [`RefundBuilder`] such that the [`Refund`] it builds is recognized by the
+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].


We need to mention the two-hour thing here, its a bit awkward its buried in the timer_tick_occurred docs. Can happen in a followup, though.

Updated in #2039.

TheBlueMatt · 2023-10-19T03:05:59Z

lightning/src/ln/channelmanager.rs

+	/// [`ChannelManager`] when handling [`Bolt12Invoice`] messages for the refund. The builder will
+	/// have the provided expiration set. Any changes to the expiration on the returned builder will
+	/// not be honored by [`ChannelManager`].
+	///


Oh also we should probably say something about how you can use abandon_payment to revoke a refund once issued (if it hasn't been paid). Its somewhat non-intuitive to me that that is true.

Updated in #2039.

jkczyz marked this pull request as ready for review September 14, 2023 22:44

jkczyz requested review from TheBlueMatt and valentinewallace September 14, 2023 22:45

jkczyz force-pushed the 2023-09-offer-utilities branch from be8bf45 to 0ff5708 Compare September 15, 2023 21:12

jkczyz mentioned this pull request Sep 15, 2023

BOLT 12 Offers message flow #2039

Merged

TheBlueMatt reviewed Sep 17, 2023

View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 0ff5708 to ff2702c Compare September 18, 2023 19:04

TheBlueMatt reviewed Sep 18, 2023

View reviewed changes

jkczyz mentioned this pull request Sep 19, 2023

Add config option to set maximum total routing fee #2417

Merged

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 087941d to 8116d6e Compare September 19, 2023 20:33

valentinewallace reviewed Sep 19, 2023

View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from 8116d6e to 2508211 Compare September 20, 2023 16:41

jkczyz commented Sep 20, 2023

View reviewed changes

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

jkczyz added this to the 0.0.117 milestone Sep 20, 2023

jkczyz mentioned this pull request Sep 18, 2023

BOLT12 Offers Tracking Issue #1970

Open

57 tasks

benthecarman reviewed Sep 25, 2023

View reviewed changes

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

TheBlueMatt modified the milestones: 0.0.117, 0.0.118 Sep 25, 2023

jkczyz force-pushed the 2023-09-offer-utilities branch from 2508211 to 7ddbd57 Compare October 11, 2023 14:37

valentinewallace reviewed Oct 12, 2023

View reviewed changes

lightning/src/onion_message/offers.rs Outdated Show resolved Hide resolved

jkczyz force-pushed the 2023-09-offer-utilities branch from 7ddbd57 to bd42eb0 Compare October 13, 2023 22:46

jkczyz commented Oct 13, 2023

View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch 2 times, most recently from 4f520cc to 6b96866 Compare October 16, 2023 13:54

TheBlueMatt reviewed Oct 18, 2023

View reviewed changes

jkczyz force-pushed the 2023-09-offer-utilities branch from e4e9fd7 to 7bf0469 Compare October 18, 2023 19:43

jkczyz force-pushed the 2023-09-offer-utilities branch from 7bf0469 to 7a198a8 Compare October 18, 2023 21:53

jkczyz mentioned this pull request Oct 18, 2023

One-hop onion message fuzz test #2671

Closed

jkczyz added 7 commits October 18, 2023 17:00

Update OnionMessenger docs for Offers

a6cd661

Avoid overloading introduction_node_id

b78cb69

Clean up onion messenger parameters and docs

a4894bd

Import msgs::OnionMessage

cfe6b95

Rename OnionMessageContents

94573dd

In preparation for needing the name OnionMessageContents for a trait to bound methods, rename it to ParsedOnionMessageContents. In the next commit, it's use will be limited to reading only, and the new trait will be a bound on method parameters instead.

valentinewallace reviewed Oct 18, 2023

View reviewed changes

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

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

lightning/src/onion_message/messenger.rs Outdated Show resolved Hide resolved

jkczyz force-pushed the 2023-09-offer-utilities branch from 7a198a8 to bf980c9 Compare October 18, 2023 23:25

jkczyz added 7 commits October 18, 2023 18:31

Allow sending onion messages to 1-hop blinded path

6dc4223

This allows for specifying the introduction node as the message recipient.

Remove outdated docs

622f7f2

Include a one-hop blinded path in Offer and Refund

80ae66a

While this doesn't add much privacy over not including any blinded paths, it allows us to exercise code for receiving on blinded paths.

Clean up peel_onion name, parameters, and docs

905028b

For consistency with other functions and doc cleanliness.

jkczyz force-pushed the 2023-09-offer-utilities branch from bf980c9 to 905028b Compare October 18, 2023 23:33

valentinewallace approved these changes Oct 18, 2023

View reviewed changes

TheBlueMatt approved these changes Oct 19, 2023

View reviewed changes

TheBlueMatt merged commit 1852715 into lightningdevkit:main Oct 19, 2023
14 of 15 checks passed

TheBlueMatt reviewed Oct 19, 2023

View reviewed changes

BOLT 12 Offers utilities #2578

BOLT 12 Offers utilities #2578

Conversation

jkczyz commented Sep 14, 2023 • edited

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 Sep 18, 2023 • edited

Choose a reason for hiding this comment

jkczyz Sep 19, 2023 • edited

Choose a reason for hiding this comment

codecov-commenter commented Sep 19, 2023 • edited

Codecov Report

valentinewallace left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkczyz Sep 20, 2023 • edited

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

jkczyz commented Oct 11, 2023

Choose a reason for hiding this comment

jkczyz left a comment

Choose a reason for hiding this comment

TheBlueMatt commented Oct 15, 2023

TheBlueMatt commented Oct 15, 2023

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

jkczyz commented Oct 18, 2023

TheBlueMatt commented Oct 18, 2023

TheBlueMatt commented Oct 18, 2023

valentinewallace left a comment

Choose a reason for hiding this comment

jkczyz commented Oct 18, 2023

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

jkczyz commented Sep 14, 2023 •

edited

TheBlueMatt Sep 18, 2023 •

edited

jkczyz Sep 19, 2023 •

edited

codecov-commenter commented Sep 19, 2023 •

edited

jkczyz Sep 20, 2023 •

edited