Onion message forwarding #10089

gijswijs · 2025-07-17T19:37:32Z

With this PR we add basic forwarding functionality for onion messages. It builds on PR #9868.

It adds OnionMessagePayload struct to the lnwire package.
It also depends on the not yet merged (PR 68)[https://github.com/lightningnetwork/lightning-onion/pull/68] in the lightning-onion package. For now it uses that package from a forked version.

The msgmux endpoint for onion messages is updated to parse the onion message packet, and forward the onion based on the acquired information.

The SubscribeOnionMessages endpoint is updated to pass along any decrypted information. This endpoint is currently solely meant for itests, although it could have practical use in the future.

gemini-code-assist

Summary of Changes

Hello @gijswijs, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces the foundational functionality for forwarding onion messages within the Lightning Network. It integrates a new OnionMessage wire protocol message, enables its routing through the existing Sphinx onion processing infrastructure, and provides RPC endpoints for sending and subscribing to these messages. This work lays the groundwork for future application-layer protocols like BOLT12 offers, allowing for privacy-preserving communication beyond just payments.

Highlights

Onion Message Wire Protocol: Introduces a new lnwire.OnionMessage type to the wire protocol, enabling the transmission of onion-encrypted messages between Lightning Network nodes. This message type is distinct from HTLC-carrying onion packets and is designed for application-layer communication.
Sphinx Onion Processing Integration: Extends the existing Sphinx onion processing logic within htlcswitch/hop to correctly parse and handle OnionMessage payloads. This includes adapting the hop iterator to recognize onion messages, extracting forwarding information (such as the NextNodeID for node-based routing), and performing message-specific TLV validations.
New RPC Endpoints for Onion Messages: Adds SendOnionMessage and SubscribeOnionMessages to the LND RPC API. These new endpoints allow external applications and users to programmatically send onion messages to peers and subscribe to a stream of incoming onion messages, facilitating the development of new privacy-preserving communication features.
Dedicated Message Endpoint and Forwarding Logic: Implements a new onion_message.OnionEndpoint that integrates with the msgmux to process incoming lnwire.OnionMessages. This endpoint is responsible for decrypting the onion blob, determining if the message is for the local node or needs forwarding, and then either dispatching it to subscribers or relaying it to the next hop in the blinded path.
Enhanced Blinded Path Handling: Introduces specific logic for blinded paths within onion messages, including the addition of NextNodeID to ForwardingInfo. This ensures that onion messages, which do not carry payment-related information like CLTV deltas or amounts, are correctly processed and forwarded along their intended blinded routes.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request introduces onion message forwarding, a significant feature that touches multiple parts of the codebase. The changes are generally well-structured, with new functionality encapsulated in the onion_message package and corresponding updates to lnwire, htlcswitch, and the RPC layer. The inclusion of integration tests for both direct and forwarded onion messages is a great addition. I've identified a few issues that need attention: a critical bug in handling dummy hops for onion messages, a high-severity issue with TLV decoding that could lead to panics, and a medium-severity issue regarding message routing logic that could cause confusion and potential bugs. Addressing these will improve the correctness and maintainability of the new functionality.

htlcswitch/hop/iterator.go

lnwire/onion_msg_payload.go

peer/brontide.go

Roasbeef · 2025-10-03T01:45:10Z

htlcswitch/hop/forwarding_info.go

+	// NextNodeID is the public key of the next node in the route. This is
+	// used by onion messages that do not necessarily care about the channel
+	// ID.
+	NextNodeID *btcec.PublicKey


I don't think we need to add this to the existing HTLC forwarding fabric at all. The only thing we care about for now is that we have a channel between the target peer (see my proposal on how we can lift this requirement).

In other words, we can make this a competely stand alone sub-system, using the actor package.

I described this in another PR, but we'd have two actors:

the processor:

In the readHandler, we read each onion message off the wire, then send it to the proecssor.

The processor takes the onion message, and transform it to figure out where to send it next. It sends it to an onion endpoint for each peer.

The onion endpoint:

When a peer connects, we make an instance of this actor, but only if it has the feature bit.

It just takes in the incoming message, and sends the onion message to the direct peer, via an interface.

You know that I love the actor package. But that PR (#9820) hasn't been reviewed yet. Adding yet another PR dependency to the onion messaging epic will make it unlikely that this will be merged anytime soon...

I think we should really aim for not building on top of this logic, because the onion messages shouldn't be piped through the switch, let's push for the actor package

Roasbeef · 2025-10-03T01:45:32Z

htlcswitch/hop/iterator.go

+
+	// isOnionMessage is a flag that indicates whether the iterator is for
+	// an onion message.
+	isOnionMessage bool


Same here, generally I think we can reduce the invasiveness of this diff, and make it much easier to review with my suggestion above.

Roasbeef · 2025-10-03T01:46:02Z

htlcswitch/hop/iterator.go

-		return nil, routeRole, err
-	}
+	if !isOnionMessage {
+		relayInfo, err := routeData.RelayInfo.UnwrapOrErr(


Yep, we wouldn't need to tangle with this code at all, just slightly duplicating the existing blinded paths processing code.

Roasbeef · 2025-10-03T01:47:13Z

onionmessage/onion_endpoint.go

+		},
+	}
+
+	resps, err := o.onionProcessor.DecodeHopIterators(


IIUC, this'll also actually cause us to hit disk for replay protection. Thinking about it a bit more: is any replay protection even defined for onion messaging?

Yes, it does. I just piggy-backed on the replay protection that's already in place in lightning-onion: https://github.com/gijswijs/lightning-onion/blob/8c58f1d4431b8d95b7c93d30d97809849d5491e1/sphinx.go#L640-L641

AFAIK there's nothing spec-wise that defines replay protection for onion messaging. I've been struggling with this a bit, but chose to keep the protection we already have.

yeah no need for reply protection.

Roasbeef · 2025-10-03T01:48:02Z

lnrpc/lightning.proto

+    // forwarding information for an onion message. It contains either
+    // next_node_id or short_channel_id for each non-final node. It MAY contain
+    // the path_id for the final node.
+    bytes encrypted_recipient_data = 5;


If this is intended for users to consume, shouldn't this be decrypted?

I'm not sure we even need this OnionMessageUpdate to be honest.
I needed it so that I could have itests that allowed me to test e2e onion messaging: Use SendOnionMessage to kick things of at Alice's end, and use SubscribeOnionMessages at Dave's end to see if everything comes through as expected.

That being said, if somebody would like to build something on top of onion message support (like LNDK is built on top of SubscribeCustomMessages), you would need SubscribeOnionMessages and you would want this to be decrypted.

Roasbeef · 2025-10-03T01:49:20Z

peer/brontide.go

 	OnionMessageServer *subscribe.Server

+	// OnionMsgSender is a function that sends an onion message to any peer.
+	OnionMsgSender func([33]byte, *btcec.PublicKey, []byte) error


Why do we need this vs just the existing SendMessage method we have? It can submit just the dest and the wire message.

Because we need to send it to a different peer. We receive the message from a peer, but we need to forward it to another peer, so we need the brontide instance of that peer. So that's why we drop in the SendOnionMessage from server.go. There we use FindPeerByPubStr and use the SendMessageLazy of that peer. I've never liked it as well, and maybe I've overlooked something, so I'm happy to improve.

Abdulkbk · 2025-10-15T17:15:28Z

Since #9868 has been merged, I think this needs to be updated, wanna take a look.

lnwire/onion_msg_payload.go

In this commit, we add two new fundamental data structures: Future[T] and Promise[T]. A future is a response that might be ready at some point in the future. This is already a common pattern in Go, we just make a type safe wrapper around the typical operations: block w/ a timeout, add a call back for execution, pipeline the response to a new future. A promise is an intent to complete a future. Typically the caller receives the future, and the callee is able to complete the future using a promise.

In this commit, we add the actual Actor implementation. We define a series of types and interfaces, that in concert, describe our actor. An actor has some ID, a reference (used to send messages to it), and also a set of defined messages that it'll accept. An actor can be implemented using a simple function if it's stateless. Otherwise, a struct can implement the Receive method, and handle its internal message passing and state that way.

This commit adds thorough test coverage for the new Mailbox interface and ChannelMailbox implementation. The tests verify correct behavior across various scenarios including successful sends, context cancellation, mailbox closure, and concurrent operations. The test suite specifically validates that the mailbox respects both the caller's context and the actor's context during send and receive operations. This ensures that actors properly shut down when their context is cancelled, and that callers can cancel operations without affecting the actor's lifecycle. Additional tests cover edge cases such as zero-capacity mailboxes (which default to a capacity of 1), draining messages after closure, and concurrent sends from multiple goroutines. The concurrent test uses 10 senders each sending 100 messages to verify thread-safety and proper message ordering. All tests pass with the race detector enabled, confirming the implementation is free from data races.

This commit refactors the Actor implementation to use the new Mailbox interface instead of directly managing a channel. This change significantly simplifies the actor's message processing loop and improves separation of concerns. The main changes include replacing the direct channel field with a Mailbox interface, updating NewActor to create a ChannelMailbox instance, and refactoring the process method to use the iterator pattern provided by mailbox.Receive. The new implementation uses a clean for-range loop over the mailbox's message iterator, eliminating the complex select statement that previously handled both message reception and context cancellation. The Tell and Ask methods in actorRefImpl have been simplified to use the mailbox's Send method, which internally handles both the caller's context and the actor's context. This eliminates the need for complex select statements in these methods and ensures consistent context handling throughout the actor system. Message draining during shutdown is now handled through the mailbox's Drain method, providing a cleaner separation between normal message processing and cleanup operations. The actor still properly sends unprocessed messages to the Dead Letter Office and completes pending promises with appropriate errors during shutdown.

Abdulkbk

gone through this again, left a few comments 🙏

Abdulkbk · 2025-11-03T16:44:57Z

lnwire/onion_msg_payload.go

+	// EncryptedData contains encrypted data for the recipient.
+	EncryptedData []byte
+
+	// FinalHopPayloads contains any tlvs with type > 64 that


incomplete comment. Also type >= 64 since it is inclusive.

lnwire/onion_msg_payload.go

+		}
+
+		if err := tlv.EPubKey(w, &p.BlindingPoint, buf); err != nil {
+			return fmt.Errorf("encode blinded path: %w", err)


Abdulkbk · 2025-11-05T13:52:23Z

htlcswitch/hop/iterator.go

 	})
-	if pathID == nil {
+
+	// If this is not an onion message, then we expect the path ID to be


Am I misinterpreting the bolt?, or does it seem like for the final node we can expect pathid to be either set or not?

Abdulkbk · 2025-11-05T14:08:29Z

htlcswitch/hop/iterator.go

+			fmt.Errorf("relay info not set for non-final blinded " +
+				"hop"),
+		)
+		cltvExpiryDelta = uint32(relayInfo.Val.CltvExpiryDelta)


nit: the error check should come before this.

Abdulkbk · 2025-11-05T16:01:41Z

htlcswitch/hop/iterator.go

+	blindingKit := BlindingKit{
+		Processor: r.router,
+		UpdateAddBlinding: tlv.SomeRecordT(
+			tlv.NewPrimitiveRecord[lnwire.BlindingPointTlvType]( //nolint:ll


nit: can remove //nolint:ll

Abdulkbk · 2025-11-05T16:23:23Z

lnwire/features.go

+
+	// OnionMessagesRequired is a required feature bit that indicates that
+	// the node can forward onion messages.
+	OnionMessagesRequired = 39


I think "even" should be the required bit right?

Abdulkbk · 2025-11-05T22:42:47Z

onionmessage/onion_endpoint.go

 	// blinded routes by default.
 	OnionBlob []byte
+
+	CustomRecords record.CustomSet


nit: go doc for CustomRecords, ReplyPath, and EncryptedRecipientData.

Abdulkbk · 2025-11-05T22:57:26Z

record/hop.go

+
+	// EncryptedRecipientDataType is the type used in the onion message to
+	// include encrypted data in the onion for use in blinded paths.
+	EncryptedRecipientDataType tlv.Type = 4


Wouldn't it make sense to use the same variable names for these as we do in onion_msg_payload for consistency?

ziggie1984

Nice to finally being able to forward onionmessages.

My main points are:

I agree with Laolu here, we should definitly not move this logic into the switch.
You mention in this PR that its all about forwarding onion_message, however in your code logic you add all the decoding and encoding of the finalHopPayload TLVs (including the replyPath) from my understanding this is all not needed. We only want to support forwarding, which means we only care about the Encrypted_Recipient_Data in this PR and treat all the other TLV types as not known. This helps to keep the PR way smaller and we would only introduce the other types when needed.

ziggie1984 · 2025-11-04T09:31:17Z

lnwire/onion_msg_payload.go

+
+const (
+	// finalHopPayloadStart is the inclusive beginning of the tlv type
+	// range that is reserved for payloads for the final hop.


the spec however says in case they are odd intermediate nodes don't need to fail it how are we planning to do it:

Field numbers 64 and above are reserved for payloads for the final hop, though these are not explicitly refused by non-final hops (unless even, of course!).

ziggie1984 · 2025-11-04T23:03:06Z

lnwire/onion_msg_payload.go

+	return &OnionMessagePayload{}
+}
+
+// Encode encodes an onion message's final payload.


I think the comment is off it encodes thee whole OnionMessagePacket ?

Nit: Moreover I think we should add a comment to funcions which are part of an interface something like:

// This is part of the lnwire.Message interface

ziggie1984 · 2025-11-04T23:12:23Z

htlcswitch/hop/forwarding_info.go

+	// NextNodeID is the public key of the next node in the route. This is
+	// used by onion messages that do not necessarily care about the channel
+	// ID.
+	NextNodeID *btcec.PublicKey


I think we should really aim for not building on top of this logic, because the onion messages shouldn't be piped through the switch, let's push for the actor package

ziggie1984 · 2025-11-04T23:15:03Z

onionmessage/onion_endpoint.go

+		},
+	}
+
+	resps, err := o.onionProcessor.DecodeHopIterators(


yeah no need for reply protection.

ziggie1984 · 2025-11-08T08:19:29Z

lnwire/onion_msg_payload.go

+	EncryptedData []byte
+
+	// FinalHopPayloads contains any tlvs with type > 64 that
+	FinalHopPayloads []*FinalHopPayload


I think we should add ExtraOpaqueData in this struct

ziggie1984 · 2025-11-08T11:02:57Z

lnwire/onion_msg_payload.go

+}
+
+// Decode decodes an onion message's payload.
+func (o *OnionMessagePayload) Decode(r io.Reader) (*OnionMessagePayload,


I do not understand this function signature, you change the pointer receiver and then you return it, that looks awkward ?

ziggie1984 · 2025-11-09T07:28:57Z

lnwire/onion_msg_payload.go

+		}
+
+		// Create a primitive record that just writes the final hop
+		// payload's bytes directly. The creating function should have


Nit: what do you mean by "directly" here ?

ziggie1984 · 2025-11-09T08:31:21Z

lnwire/onion_msg_payload.go

+	finalHopPayloadStart tlv.Type = 64
+
+	// replyPathType is a record for onion messaging reply paths.
+	replyPathType tlv.Type = 2


So accroding to he spec the reply path does only make sense for the final hop, however it is not in the range of the final hp tlv type. Wonder what the design design here was ?

ziggie1984 · 2025-11-09T09:19:20Z

lnwire/onion_msg_payload.go

+}
+
+// ReplyPath is a blinded path used to respond to onion messages.
+type ReplyPath struct {


why not just use:

type ReplyPath sphinx.BlindedPath ?

ziggie1984 · 2025-11-09T09:55:09Z

lnrpc/lightning.proto

    */
    rpc SubscribeOnionMessages (SubscribeOnionMessagesRequest)
-        returns (stream OnionMessage);
+        returns (stream OnionMessageUpdate);


could you explain to me why you changed this to Update ?

Abdulkbk · 2025-11-17T11:55:52Z

itest/lnd_onion_message_forward_test.go

+
+	// Open channels: Alice --- Bob --- Carol and wait for each node to
+	// sync the network graph.
+	aliceBobChanPoint := ht.OpenChannel(


I was considering adding an itest to verify that a channel isn't required, but I think we can probably just have a single channel from Alice -> Bob here. The expected behavior will remain the same, but at least it demonstrates that a channel isn't necessary.

* actor-mailbox-v2: actor: refactor Actor to use Mailbox interface actor: add tests for mailbox implementation actor: introduce generic Mailbox interface with iter.Seq support actor: add README.md actor: add example files actor: add the actor system and router actor: add fundamental interfaces and concrete Actor impl actor: add Future[T] and Promise[T] w/ concrete impls actor: add new actor package as distinct sub-module

The new wire message defines the OnionMessagePayload, FinalHopPayload, ReplyPath, and related TLV encoding/decoding logic.

Update lightning-onion to commit that includes onion-messaging support.

Adds the NewNonFinalBlindedRouteDataOnionMessage function to create blinded route data specifically for onion messages.

Initialize a sphinx router without persistent replay protection logging for onion message processing. Onion messages don't require replay protection since they're connectionless and don't involve payment routing.

Introduce OnionPeerActor to handle the sending of onion message to each peer. The actor is registered with the receptionist pattern to enable message routing through the actor system. Also adds onion message feature bits to the protocol, so that the actor is only spawned when the peer supports onion messages.

Add onion message forwarding capability using the OnionPeerActor for communication. Messages are routed through a receptionist pattern where each peer has a dedicated OnionPeerActor for handling message sends. The OnionEndpoint uses the sphinx router for decoding and decrypting the onion message packet and the encrypted recipient data in the payload of the onion messages.

Change SubscribeOnionMessages RPC to return OnionMessageUpdate instead of OnionMessage, including the decrypted payload to enable payload inspection in integration tests. The encrypted recipient data is still not decrypted here.

Verify that onion messages can be correctly forwarded through a multi-hop path by testing the complete flow from sender to recipient through intermediate nodes.

lightninglabs-deploy · 2025-12-08T14:25:30Z

@gijswijs, remember to re-request review from reviewers when ready

gemini-code-assist bot reviewed Jul 17, 2025

View reviewed changes

htlcswitch/hop/iterator.go Show resolved Hide resolved

lnwire/onion_msg_payload.go Outdated Show resolved Hide resolved

peer/brontide.go Outdated Show resolved Hide resolved

saubyk assigned gijswijs Jul 22, 2025

saubyk added this to lnd v0.20 Jul 22, 2025

saubyk moved this to In progress in lnd v0.20 Jul 22, 2025

gijswijs force-pushed the onion-messaging-1 branch 5 times, most recently from 9157266 to 83a36aa Compare September 1, 2025 13:53

gijswijs force-pushed the onion-messaging-1 branch from 83a36aa to 4de5d9e Compare September 4, 2025 08:48

This was referenced Sep 15, 2025

Async handling of Onion Messages with BackpressureQueue #10219

Open

[epic]: Implement Onion Messaging (BOLT4) and Support Downstream BOLT12 Features #10220

Open

gijswijs force-pushed the onion-messaging-1 branch 2 times, most recently from 953b2d8 to 3f475ce Compare September 16, 2025 09:48

gijswijs added the onion routing label Sep 16, 2025

gijswijs force-pushed the onion-messaging-1 branch from 3f475ce to 606d9e5 Compare September 17, 2025 07:55

saubyk added this to the v0.21.0 milestone Sep 24, 2025

saubyk added this to v0.21 Sep 24, 2025

saubyk removed this from lnd v0.20 Sep 24, 2025

saubyk moved this to In progress in v0.21 Sep 24, 2025

Roasbeef requested changes Oct 3, 2025

View reviewed changes

ziggie1984 changed the base branch from master to 0-21-0-staging October 18, 2025 14:48

Abdulkbk reviewed Oct 20, 2025

View reviewed changes

lnwire/onion_msg_payload.go Outdated Show resolved Hide resolved

lnwire/onion_msg_payload.go Outdated Show resolved Hide resolved

lnwire/onion_msg_payload.go Show resolved Hide resolved

lnwire/onion_msg_payload.go Show resolved Hide resolved

gijswijs force-pushed the onion-messaging-1 branch 2 times, most recently from 5a7e61d to dbb64f4 Compare October 30, 2025 12:43

Roasbeef added 3 commits October 30, 2025 17:57

actor: add new actor package as distinct sub-module

f2e83d9

Roasbeef added 2 commits October 30, 2025 19:09

yyforyongyu force-pushed the 0-21-0-staging branch 2 times, most recently from 86fd4b7 to 57eb251 Compare November 4, 2025 11:50

gijswijs force-pushed the onion-messaging-1 branch from dbb64f4 to e1738ce Compare November 5, 2025 14:23

Abdulkbk reviewed Nov 5, 2025

View reviewed changes

yyforyongyu force-pushed the 0-21-0-staging branch from 57eb251 to 6fcdbbb Compare November 7, 2025 09:15

ziggie1984 reviewed Nov 9, 2025

View reviewed changes

gijswijs force-pushed the onion-messaging-1 branch 2 times, most recently from 6b32c24 to 64828aa Compare November 12, 2025 10:54

yyforyongyu force-pushed the 0-21-0-staging branch from 706b22a to 95b84a8 Compare November 12, 2025 14:54

yyforyongyu changed the base branch from 0-21-0-staging to master November 13, 2025 08:58

Abdulkbk reviewed Nov 17, 2025

View reviewed changes

gijswijs force-pushed the onion-messaging-1 branch from 378cc05 to 271a1d6 Compare November 18, 2025 13:40

Abdulkbk mentioned this pull request Nov 27, 2025

tests for onion message forwarding gijswijs/lnd#2

Draft

gijswijs force-pushed the onion-messaging-1 branch 3 times, most recently from e25d3a6 to e6725f8 Compare December 3, 2025 14:05

gijswijs added 3 commits December 3, 2025 15:11

lnwire: add OnionMessagePayload

0fda1bb

The new wire message defines the OnionMessagePayload, FinalHopPayload, ReplyPath, and related TLV encoding/decoding logic.

go: udpate lightning-onion

fbd0746

Update lightning-onion to commit that includes onion-messaging support.

gijswijs force-pushed the onion-messaging-1 branch from e6725f8 to f887885 Compare December 3, 2025 14:12

gijswijs added 6 commits December 4, 2025 12:14

record: add func for non-final om route data

c7e722c

Adds the NewNonFinalBlindedRouteDataOnionMessage function to create blinded route data specifically for onion messages.

multi: add sphinx router without replay protection

19659c0

Initialize a sphinx router without persistent replay protection logging for onion message processing. Onion messages don't require replay protection since they're connectionless and don't involve payment routing.

lnrpc: SubscribeOnionMessages returns payload

231b462

Change SubscribeOnionMessages RPC to return OnionMessageUpdate instead of OnionMessage, including the decrypted payload to enable payload inspection in integration tests. The encrypted recipient data is still not decrypted here.

itest: add multi-hop onion message forwarding test

6d9c71a

Verify that onion messages can be correctly forwarded through a multi-hop path by testing the complete flow from sender to recipient through intermediate nodes.

gijswijs force-pushed the onion-messaging-1 branch from f887885 to 6d9c71a Compare December 4, 2025 21:02

Onion message forwarding #10089

Are you sure you want to change the base?

Onion message forwarding #10089

Uh oh!

Conversation

gijswijs commented Jul 17, 2025

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Abdulkbk commented Oct 15, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Abdulkbk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ziggie1984 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ziggie1984 left a comment •

edited

Loading