p2p: Don't participate in addr relay with feelers #34997

danielabrozzoni commented at 4:16 PM on April 3, 2026: member

Feeler connections are short-lived connection made to check that a node is alive, useful for test-before-evict, and for moving addresses from the new to the tried table.

We currently send a GETADDR message to feelers, but then disconnect before being able to receive a response. This GETADDR is not useful and can be removed.

I couldn't find any previous discussion about this, but I found PR #22777, that similarly made sure that we don't ask for tx relay to feelers.

I noticed this behavior on my peer-observer instance: I would see the number of sent GETADDR messages increase over time, but the number of ADDR messages with >100 addresses received (which are likely GETADDR responses and not self announcements relays) wouldn't increase as much. I later realized that it was my node opening feeler connections, sending a GETADDR, and closing the connection.

You can see the same behavior using this command - the node is making feeler connections, sending getaddr to them, closing before receiving the addr response:

~ ₿ tail -f ~/.bitcoin/debug.log | grep -E "(Making feeler connection|Added connection to|sending getaddr|feeler connection completed|Received addr: [0-9]{2,} addresses)"

2026-04-02T13:25:50Z [net] Making feeler connection to xyz.onion:8333
2026-04-02T13:26:06Z [net] Added connection to xyz.onion:8333 peer=27
2026-04-02T13:26:08Z [net] sending getaddr (0 bytes) peer=27
2026-04-02T13:26:08Z [net] feeler connection completed, disconnecting peer=27, peeraddr=xyz.onion:8333

On a node that accepts inbounds connections, this command can be used to see in the logs all the nodes that connected, sent a getaddr, and disconnected before receiving a reply. It is possible that these nodes connected to us as a feeler:

~ ₿ cat .bitcoin/debug.log | awk '

  /received: getaddr/ {
      split($0, a, "peer=")
      got_getaddr[a[2]] = $0
  }

  /sending addr/ {
      split($0, a, "peer=")
      sent_addr[a[2]] = 1
  }

  /socket closed/ {
      split($0, a, "peer=")
      id = a[2]

      if (id in got_getaddr && !(id in sent_addr)) {
          print "possible feeler: " got_getaddr[id]
          print "                 " $0
      }

      delete got_getaddr[id]
      delete sent_addr[id]
  }
'

possible feeler: 2026-04-01T21:45:13Z [net] received: getaddr (0 bytes) peer=2311974
                 2026-04-01T21:45:13Z [net] socket closed, disconnecting peer=2311974
possible feeler: 2026-04-02T00:18:58Z [net] received: getaddr (0 bytes) peer=2426389
                 2026-04-02T00:18:58Z [net] socket closed, disconnecting peer=2426389
...

Then, you can manually inspect one of them:

~ ₿ cat .bitcoin/debug.log | grep -E "peer=2311974"
2026-04-01T21:45:13Z [net] Added connection peer=2311974
2026-04-01T21:45:13Z [net] received: version (102 bytes) peer=2311974
2026-04-01T21:45:13Z [net] sending version (102 bytes) peer=2311974
2026-04-01T21:45:13Z [net] send version message: version 70016, blocks=943279, txrelay=0, peer=2311974
2026-04-01T21:45:13Z [net] sending wtxidrelay (0 bytes) peer=2311974
2026-04-01T21:45:13Z [net] sending sendaddrv2 (0 bytes) peer=2311974
2026-04-01T21:45:13Z [net] sending verack (0 bytes) peer=2311974
2026-04-01T21:45:13Z [net] receive version message: /Satoshi:27.0.0/: version 70016, blocks=943279, us=x.x.x.x:8333, txrelay=0, peer=2311974
2026-04-01T21:45:13Z [net] received: wtxidrelay (0 bytes) peer=2311974
2026-04-01T21:45:13Z [net] received: sendaddrv2 (0 bytes) peer=2311974
2026-04-01T21:45:13Z [net] received: verack (0 bytes) peer=2311974
2026-04-01T21:45:13Z New inbound v1 peer connected: version: 70016, blocks=943279, peer=2311974
2026-04-01T21:45:13Z [net] sending sendcmpct (9 bytes) peer=2311974
2026-04-01T21:45:13Z [net] sending ping (8 bytes) peer=2311974
2026-04-01T21:45:13Z [net] sending getheaders (1029 bytes) peer=2311974
2026-04-01T21:45:13Z [net] initial getheaders (943278) to peer=2311974 (startheight:943279)
2026-04-01T21:45:13Z [net] received: getaddr (0 bytes) peer=2311974
2026-04-01T21:45:13Z [net] Advertising address x.x.x.x:8333 to peer=2311974
2026-04-01T21:45:13Z [net] socket closed, disconnecting peer=2311974
2026-04-01T21:45:13Z [net] Resetting socket for peer=2311974
2026-04-01T21:45:13Z [net] sending addrv2 (24665 bytes) peer=2311974
2026-04-01T21:45:13Z [net] Cleared nodestate for peer=2311974

DrahtBot added the label P2P on Apr 3, 2026

DrahtBot commented at 4:16 PM on April 3, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34997.

Reviews

See the guideline and AI policy for information on the review process.

Type	Reviewers
ACK	andrewtoth, 0xB10C, stratospher, achow101
Concept ACK	ajtowns, mzumsande, naiyoma, taki-abedesselam
Stale ACK	brunoerg, vasild

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

taki-abedesselam commented at 1:59 PM on April 4, 2026: none

Concept ACK, I suggest adding this conndition at https://github.com/bitcoin/bitcoin/blob/a7c30da1f6fc2eebd7514dd032fbb54940d467de/src/net_processing.cpp#L4823 So the bitcoin client will not respond to any GETADDR message from a feeler connection or outbound connections

if (!pfrom.IsInboundConn() || pfrom.IsFeelerConn()) {
            LogDebug(BCLog::NET, "Ignoring \"getaddr\" from %s connection. peer=%d\n", pfrom.ConnectionTypeAsString(), pfrom.GetId());
            return;
}

danielabrozzoni commented at 9:15 AM on April 6, 2026: member

Thanks @taki-abedesselam!

I suggest adding this conndition at

https://github.com/bitcoin/bitcoin/blob/a7c30da1f6fc2eebd7514dd032fbb54940d467de/src/net_processing.cpp#L4823

So the bitcoin client will not respond to any GETADDR message from a feeler connection or outbound connections

I don't think this is going to work:

for outbound connections (us connecting to a feeler), if the feeler node sends us a getaddr we are already going to ignore the message, because of !pfrom.IsInboundConn()
for inbound connections (some other node treating us as a feeler), we don't know that the other node is using us as a feeler, we simply see "someone connected to us and quickly disconnected", we have no way of selectively ignoring their getaddr.

ajtowns commented at 10:27 AM on April 6, 2026: contributor

I guess if we have 8 outbounds sustained (and are not already eclipsed), then we likely get fairly good addr information constantly, and if we don't have 8 outbounds, we'll keep making new outbound connections, send a GETADDR to them, and get back 1000 new addressed, so one way or the other will get good coverage. So I guess we don't need to put in any extra effort to get better address coverage, in the same way that we put in extra-effort via extra-block-relay-only peers to ensure we don't miss out on any higher-PoW blocks.

Getting addresses from feeler connections is probably low-quality: those are the addresses we think might not even be running a bitcoin node. So this seems fine from that perspective too.

I find addrfetch connections confusing every time I think about them; I wish they were called addrseed or something instead. In any event, they're only really meaningful for initially populating your addrman when your node is either fresh or has been down for a while. If we were wanting to do something better, doing that via additional addrfetch connections would probably be more reasonable than doing it via feeler connections.

Concept ACK.

in src/net_processing.cpp:3754 in 04718e1d98 outdated

3747 | @@ -3748,9 +3748,9 @@ void PeerManagerImpl::ProcessMessage(Peer& peer, CNode& pfrom, const std::string
3748 |  
3749 |          // Attempt to initialize address relay for outbound peers and use result
3750 |          // to decide whether to send GETADDR, so that we don't send it to
3751 | -        // inbound or outbound block-relay-only peers.
3752 | +        // inbound, feelers, or outbound block-relay-only peers.
3753 |          bool send_getaddr{false};
3754 | -        if (!pfrom.IsInboundConn()) {
3755 | +        if (!pfrom.IsInboundConn() && !pfrom.IsFeelerConn()) {
3756 |              send_getaddr = SetupAddressRelay(pfrom, peer);

ajtowns commented at 10:28 AM on April 6, 2026:

We drop out of SetupAddressRelay for blocks-only nodes rather than gating calls to it. Maybe we should do feelers there too?

yancyribbens commented at 1:52 PM on April 6, 2026: contributor

I'm not very familiar with "feelers", although, wouldn't the quality of the data returned by feelers be better if we waited for the results of the GETADDR message instead of the current behavior of disconnecting before receiving the result?

mzumsande commented at 12:50 PM on April 9, 2026: contributor

Concept ACK

This saves a little bit of bandwidth (not just our GETADDR message, but also their ADDR answer that the peer might prepare before they recognize they are being disconnected) but shouldn't change anything else.

I'm not very familiar with "feelers", although, wouldn't the quality of the data returned by feelers be better if we waited for the results of the GETADDR message

They wouldn't really be feeler anymore then. The current scope of feelers is just to know if there is a bitcoin node behind an address, not to get data from them. We could extend the scope in various ways (it has already been suggested in the past to exchange headers/compare the tip with them before disconnecting), but this should follow some sort of need. I agree with @ajtowns that currently there doesn't really seem to be a need for more addresses - if we extend the scope I think that the tip sync may be more important).

danielabrozzoni force-pushed on Apr 9, 2026

danielabrozzoni commented at 2:18 PM on April 9, 2026: member

Thanks for the reviews!

I spent some time thinking about https://github.com/bitcoin/bitcoin/pull/34997/changes#r3039010154, and I realized that it makes more sense to disable address relay altogether, instead of simply not sending the getaddr. I was initially thinking along the lines of "we might still want to receive and relay the peer self announcement, or send our self announcement". However:

From logs, it seems to me that we disconnect quickly enough that this doesn't happen. What I saw on my machines was simply nodes sending a GETADDR to feelers, and disconnecting right away.
Even assuming that there is time for this message exchange, if we drop the initial GETADDR, we won't send any self announcement to the peer, because addr relay won't be initialized: https://github.com/bitcoin/bitcoin/blob/d2844c6a4ffa39ec365009777cd87caf1fbab867/src/net_processing.cpp#L5443-L5446 Similarly, the peer won't send any self announcement to us, because they never receive an ADDR/GETADDR that initializes address relay.

So, since not sending a GETADDR already disables address relay altogether, I might as well be a bit more clear and do so in SetupAddressRelay.

In my last push (04718e1d984d7722c8e74e41156aa93ec18be83d -> d263660b9ba516e9145da9cbadff262fe26fc2b5):

Disable address relay for feelers in SetupAddressRelay, instead of simply not sending the GETADDR to feelers
Update commit title / message to reflect that we are disabling all address relay to feelers

danielabrozzoni force-pushed on Apr 9, 2026

DrahtBot added the label CI failed on Apr 9, 2026

danielabrozzoni renamed this:
~~p2p: Don't send a GETADDR to feelers~~
p2p: Don't participate in addr relay with feelers
on Apr 9, 2026

danielabrozzoni force-pushed on Apr 9, 2026

DrahtBot removed the label CI failed on Apr 9, 2026

danielabrozzoni commented at 8:56 PM on April 9, 2026: member

Sorry, had to push again to retrigger CI, I hit #34849

Last push (d263660 -> 3934d95): no changes, commit amend to retrigger CI

naiyoma commented at 8:57 PM on April 13, 2026: contributor

Concept ACK

It's pointless to allow Feeler connections to participate in addr relay. I've been able to observe what you've shared above . We send getaddr, and then disconnection happens quickly before we get a response.

2026-04-13T20:30:54Z [net] Added connection to 69.36.61.139:8333 peer=70
2026-04-13T20:30:55Z [net] start sending v2 handshake to peer=70
2026-04-13T20:30:56Z [net] sending version (103 bytes) peer=70
2026-04-13T20:30:56Z [net] send version message: version=70016, blocks=713357, them=69.36.61.139:8333, txrelay=0, peer=70
2026-04-13T20:31:00Z [net] received: version (102 bytes) peer=70
2026-04-13T20:31:00Z [net] receive version message: /Satoshi:27.0.0/: version 70016, blocks=944938, us=129.222.147.237:21739, txrelay=1, peer=70 peeraddr=69.36.61.139:8333
2026-04-13T20:31:00Z [net] sending wtxidrelay (0 bytes) peer=70
2026-04-13T20:31:00Z [net] sending sendaddrv2 (0 bytes) peer=70
2026-04-13T20:31:00Z [net] sending verack (0 bytes) peer=70
2026-04-13T20:31:00Z [net] sending getaddr (0 bytes) peer=70
2026-04-13T20:31:00Z [net] feeler connection completed, disconnecting peer=70 peeraddr=69.36.61.139:8333

in test/functional/p2p_add_connections.py:117 in 3934d95408

 112 | @@ -113,6 +113,8 @@ def run_test(self):
 113 |          assert_equal(feeler_conn.message_count["version"], 1)
 114 |          # Feeler connections do not request tx relay
 115 |          assert_equal(feeler_conn.last_message["version"].relay, 0)
 116 | +        # We don't send a GETADDR to feelers
 117 | +        assert_equal(feeler_conn.message_count["getaddr"], 0)

naiyoma commented at 9:02 PM on April 13, 2026:

I think it's better to add this test to p2p_addr_relay.py https://github.com/bitcoin/bitcoin/blob/master/test/functional/p2p_addr_relay.py#L283

fits with this existing test case -> Check that we do not send a getaddr message to a block-relay-only or inbound peer

brunoerg commented at 1:46 PM on April 15, 2026:

~0. Looks better to add this to p2p_addr_relay.py but it would require to create a new connection, and probably move P2PFeelerReceiver to util to not duplicate code. Since we already have a feeler connection in p2p_add_connections, just adding one more assertion looks simpler.

danielabrozzoni commented at 8:36 AM on April 24, 2026:

I ended up taking this - I think it's a bit cleaner, and serves as documentation for how getaddr works.

I implemented it using AddrReceiver instead of reusing P2PFeelerReceiver, since the latter is only an optimization to avoid sending useless messages into a closing connection: P2PFeelerReceiver only sends a version message upon receiving a version message, while the AddrReceiver also sends wtxidrelay, sendaddrv2 - all of which go into a dead socket, since bitcoind closes the feeler connection as soon as version is received.

So, using AddrReceiver is slightly less clean, but harmless otherwise.

naiyoma commented at 11:23 AM on April 14, 2026: contributor

On a node that accepts inbounds connections, this command can be used to see in the logs all the nodes that connected, sent a getaddr, and disconnected before receiving a reply. It is possible that these nodes connected to us as a feeler: 2026-04-01T21:45:13Z [net] socket closed, disconnecting peer=2311974 2026-04-01T21:45:13Z [net] Resetting socket for peer=2311974 2026-04-01T21:45:13Z [net] sending addrv2 (24665 bytes) peer=2311974

Yeah, I think this is a feeler

What I find interesting about this is that we are sending an addr message after the socket has been closed. This would mean that the message doesn’t reach the recipient ?, Compared to what I think is the normal flow, sending happens before disconnecting.

2026-04-08T08:38:25Z [net] sending addrv2 (23063 bytes) peer=31
2026-04-08T08:39:06Z [net] socket closed, disconnecting peer=31 peeraddr=127.0.0.1:47158
2026-04-08T08:39:06Z [net] Resetting socket for peer=31 peeraddr=127.0.0.1:47158
2026-04-08T08:39:06Z [net] Cleared nodestate for peer=31

brunoerg commented at 1:35 PM on April 15, 2026: contributor

Concept ACK

brunoerg approved

brunoerg commented at 4:34 PM on April 15, 2026: contributor

ACK 3934d954082c7f467ed24371b20f4875743bc324

Avoiding feelers on addr relay makes total sense. Code lgtm since now it's skipping feelers on SetupAddressRelay. I'm fine on testing it on p2p_add_connections.py (for reference: https://github.com/bitcoin/bitcoin/pull/34997/changes#r3075804504) and verified this is enough to catch the following mutant:

diff --git a/src/net_processing.cpp b/src/net_processing.cpp
index c7005ddaec..1b7cac8375 100644
--- a/src/net_processing.cpp
+++ b/src/net_processing.cpp
@@ -5616,7 +5616,7 @@ bool PeerManagerImpl::SetupAddressRelay(const CNode& node, Peer& peer)
     // they are short-lived connections made for test-before-evict or to
     // promote addresses from addrman's new table to the tried table, and
     // are disconnected shortly after the handshake completes.
-    if (node.IsFeelerConn()) return false;
+    if (node.IsFeelerConn()) return true;

     if (!peer.m_addr_relay_enabled.exchange(true)) {
         // During version message processing (non-block-relay-only outbound peers)

DrahtBot requested review from naiyoma on Apr 15, 2026

DrahtBot requested review from ajtowns on Apr 15, 2026

DrahtBot requested review from mzumsande on Apr 15, 2026

danielabrozzoni force-pushed on Apr 24, 2026

danielabrozzoni commented at 8:37 AM on April 24, 2026: member

In my last push (3934d95 -> 5bb1a9bc464f8b958cdbc40ae6b0a98a8b0397e4):

Move test from p2p_add_connections.py to p2p_addr_relay.py (see #34997 (review))

Sorry for invalidating your ACK @brunoerg!

sedited requested review from brunoerg on May 2, 2026

brunoerg commented at 5:45 PM on May 4, 2026: contributor

reACK 5bb1a9bc464f8b958cdbc40ae6b0a98a8b0397e4

checked the functional test change since my last review.

in src/net_processing.cpp:5618 in 5bb1a9bc46

5611 | @@ -5615,6 +5612,12 @@ bool PeerManagerImpl::SetupAddressRelay(const CNode& node, Peer& peer)
5612 |      // information of addr traffic to infer the link.
5613 |      if (node.IsBlockOnlyConn()) return false;
5614 |  
5615 | +    // We don't participate in addr relay with feeler connections because
5616 | +    // they are short-lived connections made for test-before-evict or to
5617 | +    // promote addresses from addrman's new table to the tried table, and
5618 | +    // are disconnected shortly after the handshake completes.

andrewtoth commented at 8:11 PM on May 10, 2026:

I don't think this comment needs to describe what the feeler connections are useful for. That is better documented in https://github.com/bitcoin/bitcoin/blob/master/src/node/connection_types.h.

We should instead document here the specific behavior that makes it desirable to skip addr relay for feeler connections.

Something like:

    // We don't participate in addr relay with feeler connections because
    // they are disconnected shortly after the handshake completes,
    // before the node will receive the addr response. Also, the addresses
    // from feelers are likely low quality, given that they come from
    // addresses we're not even sure are running a Bitcoin node.

andrewtoth commented at 8:16 PM on May 10, 2026: contributor

ACK 5bb1a9bc464f8b958cdbc40ae6b0a98a8b0397e4

Makes sense to skip addr relay for feelers since we don't even wait for the response.

in src/net_processing.cpp:3749 in 5bb1a9bc46 outdated

3747 | @@ -3750,7 +3748,7 @@ void PeerManagerImpl::ProcessMessage(Peer& peer, CNode& pfrom, const std::string
3748 |  
3749 |          // Attempt to initialize address relay for outbound peers and use result

vasild commented at 9:36 AM on May 11, 2026:

In the commit message:

Feeler connections are short-lived connections made to check that a node is alive, useful for test-before-evict ...

Maybe clarify that this is about eviction from addrman. We also "evict" live connections (peers that we are connected to), in CConnman::AttemptToEvictConnection(), which is a different type of "eviction".

in src/net_processing.cpp:3750 in 5bb1a9bc46 outdated

3747 | @@ -3750,7 +3748,7 @@ void PeerManagerImpl::ProcessMessage(Peer& peer, CNode& pfrom, const std::string
3748 |  
3749 |          // Attempt to initialize address relay for outbound peers and use result
3750 |          // to decide whether to send GETADDR, so that we don't send it to

vasild commented at 9:41 AM on May 11, 2026:

In the commit message:

the addresses from feelers are likely low quality, given that they come from addresses we're not even sure are running a Bitcoin node.

Hmm? I think the quality of addresses is all the same from all nodes we talk to (unless we walk to a "trusted" node that we control).

danielabrozzoni commented at 2:18 PM on May 12, 2026:

I initially took the reasoning from #34997 (comment), but re-reading my commit message, I'm a bit confused too 😅 Sorry about that.

In my understanding, feeler connections are made to:

addresses already in the tried table (we connected to them at least once), but which may get evicted due to collisions, and so we want to check if they're still alive.
in absence of collisions, addresses from the new table, which are the "addresses we're not even sure are running a Bitcoin node"

However, once we have connected to 2., we are sure they are running a Bitcoin node :) So I don't really see why their addresses might be lower quality. @ajtowns can you clarify the point you made earlier?

stratospher commented at 12:33 PM on July 8, 2026:

(not related to this address quality thread)

However, once we have connected to 2., we are sure they are running a Bitcoin node

1 exception I've come across is a spy node cluster which can listen but doesn't run a node.

in src/net_processing.cpp:5612 in 5bb1a9bc46 outdated

5611 | @@ -5615,6 +5612,12 @@ bool PeerManagerImpl::SetupAddressRelay(const CNode& node, Peer& peer)
5612 |      // information of addr traffic to infer the link.

vasild commented at 9:50 AM on May 11, 2026:

There are some other messages that we might as well skip for feeler connections. Worth exploring for a followup.

vasild approved

vasild commented at 9:50 AM on May 11, 2026: contributor

ACK 5bb1a9bc464f8b958cdbc40ae6b0a98a8b0397e4

danielabrozzoni commented at 2:18 PM on May 12, 2026: member

Thanks for the review! I plan to update to fix the documentation and commit message once I have clarity around #34997 (review), so I'll invalidate everyone's ACK soon - sorry!

0xB10C commented at 8:17 PM on May 12, 2026: contributor

Concept ACK!

taki-abedesselam commented at 12:22 PM on May 14, 2026: none

Concept ACK!

sedited commented at 9:11 AM on July 4, 2026: contributor

@danielabrozzoni what is the status here? This hasn't received an update in a while. Are you still waiting for an answer to your question here: #34997 (review) ?

danielabrozzoni commented at 1:13 PM on July 6, 2026: member

@sedited sorry for the delay! Yes, I was, but I can also push an update reshaping the commit message, so that it doesn't include that sentence anymore. Will do soon! :)

p2p: Don't participate in addr relay with feeler connections

Feeler connections are short-lived connections made to check that a node
is alive, useful for test-before-evict from addrman, and for moving
addresses from the new to the tried table.

We currently send a GETADDR message to feelers, but then disconnect
before being able to receive a response. This wastes some bandwidth, so
we can avoid sending the GETADDR altogether.

Not sending the initial GETADDR will effectively disable addr relay:
we initialize addr relay for the peer when we send GETADDR, and the peer
initializes addr relay to us when they receive it. So the
peer will not relay any announcement to us, and we will not relay any
to them either. This is ok, since the use of feelers is to test if there
is a bitcoin node behind an address, not exchange addresses with them.

b0735336ee

danielabrozzoni force-pushed on Jul 6, 2026

danielabrozzoni commented at 2:05 PM on July 6, 2026: member

In my last push (5bb1a9b -> b0735336eed9d79d1b1148eff16533cb2d862c01):

Dropped the possibly imprecise sentence from the commit message about addresses from feelers being lower quality (see #34997 (review))
Clarified in the commit message that not sending the GETADDR will disable addr relay altogether
Clarified in the commit message that "test before evict" refers to eviction from addrman (see #34997 (review))
Updated the code comment to focus on why we don't participate in addr relay with feelers, instead of describing what feeler connections are (https://github.com/bitcoin/bitcoin/pull/34997#discussion_r3227151668)

andrewtoth approved

andrewtoth commented at 3:02 PM on July 6, 2026: contributor

ACK b0735336eed9d79d1b1148eff16533cb2d862c01

DrahtBot requested review from 0xB10C on Jul 6, 2026

DrahtBot requested review from vasild on Jul 6, 2026

0xB10C commented at 12:03 PM on July 8, 2026: contributor

ACK b0735336eed9d79d1b1148eff16533cb2d862c01

I only looked at the code. Didn't do any manual testing of this.

stratospher commented at 12:38 PM on July 8, 2026: contributor

ACK b073533. didn't see any addr message from feelers in my node's last 24 hours/it would disconnect before addr message is received. so consistent with today's behaviour.

achow101 commented at 6:35 PM on July 8, 2026: member

ACK b0735336eed9d79d1b1148eff16533cb2d862c01

achow101 merged this on Jul 8, 2026

achow101 closed this on Jul 8, 2026