[DNM] Implements IP utilization tracking for networks by aepifanov · Pull Request #50450 · moby/moby

aepifanov · 2025-07-18T21:48:07Z

- What I did

This PR introduces IP utilization tracking for Docker networks by extending the network inspection API to include IPAM state. This enhancement allows users to monitor how many IP addresses are allocated per subnet and IP range pool within a network.
It covers only IPv4.

- How I did it

Design IP-utilization

Added IP allocation counters to track usage within:
- The entire subnet
- The defined IP range pool
Introduced new API types to represent network State, including nested IPAM state information
Implemented support and test coverage for the following network drivers:
- bridge
- macvlan
- ipvlan
- overlay

Example output from docker network inspect:

> docker network inspect my
[
    {
        "Name": "my",
....
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "192.168.10.0/24",
                    "IPRange": "192.168.10.128/31",
                    "Gateway": "192.168.10.1",
                    "AuxiliaryAddresses": {
                        "my-host": "192.168.10.128"
                    }
                }
            ]
        },
        "State": {
            "IPAM": {
                "192.168.10.0/24": {
                    "AllocatedIPsInSubnet": 4,
                    "AvailableIPsInIPRangePool": 1
                }
            }
        },
....
    }
]

AllocatedIPsInSubnet: Number of addresses allocated in the subnet. If the value exceeds uint64, it is capped at the maximum uint64 value.
AvailableIPsInIPRangePool: Number of available addresses for allocating in the IP range pool.

Depends on:

IP utilization in Swarm

- How to verify it

Run docker network inspect <network> and verify the new State.IPAM section reflects real-time allocation counts for each subnet configuration.

- Human readable description for the release notes

Implements IP utilization tracking for Docker networks.
Adds IP allocation counters to network inspect responses.

- A picture of a cute animal (not mandatory but encouraged)

corhere

How come you need both the PoolData.allocatedIPsInPool counters and (*addrset.AddrSet).Selected()? Aren't all reserved IPs added to an AddrSet? I would have expected .Selected() to be sufficient.

aepifanov · 2025-07-23T15:05:29Z

@corhere

How come you need both the PoolData.allocatedIPsInPool counters and (*addrset.AddrSet).Selected()? Aren't all reserved IPs added to an AddrSet? I would have expected .Selected() to be sufficient.

allocatedIPsInPool counts the IP addresses allocated specifically from the IP range pool
allocatedIPsInSubnet tracks allocations from the entire subnet

corhere · 2025-07-23T15:10:16Z

allocatedIPsInPool counts the IP addresses allocated specifically from the IP range pool
allocatedIPsInSubnet tracks allocations from the entire subnet

Could you please elaborate further? I still do not understand why the information from the AddrSet is incomplete.

aepifanov · 2025-07-23T15:27:45Z

allocatedIPsInPool counts the IP addresses allocated specifically from the IP range pool
allocatedIPsInSubnet tracks allocations from the entire subnet

Could you please elaborate further? I still do not understand why the information from the AddrSet is incomplete.

allocatedIPsInSubnet matches 1:1 with .Selected() from the AddrSet, as it counts all IPs allocated from the entire subnet.
allocatedIPsInPool is calculated based on matches against the configured ip-range, which is defined at the PoolData level and stored as a children map:

moby/daemon/libnetwork/ipams/defaultipam/structures.go

Lines 18 to 25 in addc373

    
           // PoolData contains the configured pool data 
        
           type PoolData struct { 
        
           	addrs    *addrset.AddrSet 
        
           	children map[netip.Prefix]struct{} 
        
           	// Whether to implicitly release the pool once it no longer has any children. 
        
           	autoRelease bool 
        
           }

corhere · 2025-07-23T15:58:10Z

Okay, I think I understand. I am not entirely thrilled with there being two sources of truth for the IP address allocations, but you may have had a good reason to take this approach. Which alternative solutions did you consider and why did the approach of maintaining a running counter win out?

aepifanov · 2025-07-25T17:14:14Z

@corhere I've done the following changes from the last your review:

removed ipv6 support
reversed the counter for ip-range pool from used to available
extened the integratio tests with using aux-addresses
changed the State.IPAM format to:

        "State": {
            "IPAM": {
                "192.168.10.0/24": {
                    "AllocatedIPsInSubnet": 5,
                    "AvailableIPsInIPRangePool": 1
                }
        },

corhere

It does not look like the tests cover all the corner cases.

corhere · 2025-07-25T17:46:04Z

daemon/libnetwork/internal/addrset/addrset.go

+	bits := as.pool.Addr().BitLen() - as.pool.Bits()
+	// If there are no bitmaps, all addresses are unselected.
+	if len(as.bitmaps) == 0 {
+		return 0
+	}
+	bms := uint64(1)
+	// If the subnet is bigger than Bitmap's capacity, calculate the number of bitmaps we have.
+	if bits > maxBitsPerBitmap {
+		bms = 1 << (bits - maxBitsPerBitmap)
+	}
+
+	// Calculate the number of selected addresses in each bitmap.
+	for _, bm := range as.bitmaps {
+		if bms > 0 {
+			bms--
+		}


What's the purpose of the bits and bms variables? Neither one is used in the summation.

Outdated code. Removed.

corhere · 2025-07-25T17:49:07Z

daemon/libnetwork/internal/addrset/addrset.go

+	// If there are no bitmaps, all addresses are unselected.
+	if len(as.bitmaps) == 0 {
+		return 0
+	}


Nit: premature optimization. The loop body would execute zero times, leading to the correct answer of zero addresses selected without any wasted cycles.

corhere · 2025-07-25T19:26:39Z

daemon/libnetwork/ipams/defaultipam/allocator.go


-func newPoolData(pool netip.Prefix) *PoolData {
-	h := addrset.New(pool)
+func newPoolData(pool, sub netip.Prefix) *PoolData {


What is the rationale behind changing the signature of newPoolData?

The idea was to handle usedInRangePool counter during the PoolData initialization steps, which required the sub info as well.
But it's outdated code for now.

corhere · 2025-07-25T19:29:55Z

daemon/libnetwork/ipams/defaultipam/allocator.go

 	bits := pool.Addr().BitLen() - pool.Bits()
 	if !pool.Addr().Is4() || bits > 1 {
-		h.Add(pool.Addr())
+		pd.RequestAddress(pool, netip.Prefix{}, netip.Addr{}, nil)


How is this equivalent to pd.addrs.Add(pool.Addr()) when you aren't passing pool.Addr() as a parameter?

After re-implementation of usedInIPRangePool calculation it's returned back.

corhere · 2025-07-25T19:51:55Z

daemon/libnetwork/ipams/defaultipam/structures.go

 	children map[netip.Prefix]struct{}

+	// The number of addresses allocated in the pool.
+	allocatedIPsInPool uint64


From our earlier discussions I understand that this is not actually the count of addresses allocated in the nw as a whole, since that would be duplicating (PoolData).addrs.Selected(). What is counting, then? I don't see how a single integer could be used to report how many addresses are available for dynamic allocation in a specific sub without interference from other subs under the same nw shared with other container networks.

Nice catch!
I've re-implemented usedInIPRangePool handling method to the direct calculation of the selected addresses in a bitmap for a specified range, which allows to get the actual IPAM state for any range.

corhere · 2025-07-25T19:55:42Z

daemon/libnetwork/ipams/defaultipam/allocator.go

+//     and should no longer be modified.
+func (a *Allocator) GetAllocatedIPs(poolID string) (allocatedIPsInSubnet, allocatedIPsInPool uint64, err error) {
+	log.G(context.TODO()).Debugf("GetAllocatedIPs(%s)", poolID)
+	k, err := PoolIDFromString(poolID)


I don't see k.ChildSubnet consumed anywhere. How can the count of addresses allocated in that range be looked up without knowing which range to count?

In the current implementation the range is taken from the PoolID which contains it.

corhere · 2025-07-25T20:00:04Z

daemon/libnetwork/network.go

+			if !cidr.Addr().Is4() {
+				return 0, fmt.Errorf("IPAM state only supports IPv4 CIDRs, got %s", cidr)
+			}
+			return uint64(1) << (32 - cidr.Bits()), nil


We can do better than hardcode a constant:

Suggested change

return uint64(1) << (32 - cidr.Bits()), nil

return uint64(1) << (cidr.Addr().BitLen() - cidr.Bits()), nil

corhere · 2025-07-25T20:08:41Z

daemon/libnetwork/ipams/defaultipam/address_space_test.go

+			as, err := newAddrSpace(tc.predefined)
+			assert.NilError(t, err)
+
+			err = as.allocateSubnet(tc.subnet, tc.ipRange)


Where are you testing the cases with multiple ip-range allocations under a single subnet? Be sure to cover both the disjoint ranges (e.g. --subnet 192.168.0.0/24 --ip-range 192.168.0.0/25, --subnet 192.168.0.0/24 --ip-range 192.168.0.128/25) and overlapping ranges (e.g. --subnet 192.168.0.0/24 --ip-range 192.168.0.0/25, --subnet 192.168.0.0/24 --ip-range 192.168.0.64/26) cases

Added test-cases.

corhere · 2025-08-05T18:28:02Z

daemon/cluster/convert/network.go

+	netState := &network.NetworkState{}
+	if n.State != nil {
+		if err := json.Unmarshal(n.State.Value, netState); err != nil {
+			log.G(context.TODO()).WithError(err).Warnf("Failed to unmarshal network state for network %s", n.ID)
+		}
+	}
+	if netState.IPAM == nil {
+		netState = nil
+	}


The daemon instance converting the swarmapi.Network to a network.Inspect might not be the same process, let alone the same version, as the one that produced the swarmapi.Network value. Could you please future-proof the conversion to gracefully handle network state values of unexpected types? Having the consumer assume a particular schema of the Any value hampers our flexibility to change how the network state is encoded.

corhere · 2025-08-05T18:31:25Z

daemon/libnetwork/bitmap/sequence.go

+	for remaining > 0 {
+		if cur.count <= remaining {
+			selected += uint64(bits.OnesCount32(cur.block)) * cur.count
+			remaining -= cur.count
+			cur = cur.next
+		} else {
+			selected += uint64(bits.OnesCount32(cur.block)) * remaining
+			remaining = 0
+		}
+	}


Recent versions of Go now have convenient max and min builtins.

Suggested change

for remaining > 0 {

if cur.count <= remaining {

selected += uint64(bits.OnesCount32(cur.block)) * cur.count

remaining -= cur.count

cur = cur.next

} else {

selected += uint64(bits.OnesCount32(cur.block)) * remaining

remaining = 0

}

}

for remaining > 0 {

n := min(cur.count, remaining)

selected += uint64(bits.OnesCount32(cur.block)) * n

remaining -= n

cur = cur.next

}

corhere · 2025-08-05T18:53:34Z

daemon/libnetwork/bitmap/sequence.go

+// CalculateSelected calculates the number of selected bits in the range [start, end].
+func (h *Bitmap) CalculateSelected(start, end uint64) (uint64, error) {


Bikeshedding: name functions based on their outputs and side effects, not on irrelevant implementation details. It makes no difference to the caller whether the number of set bits is calculated on the fly, cached, memoized, indexed, etc., so long as it gets the correct answer.

Suggested change

// CalculateSelected calculates the number of selected bits in the range [start, end].

func (h *Bitmap) CalculateSelected(start, end uint64) (uint64, error) {

// OnesCount calculates the number of selected bits in the range [start, end].

func (h *Bitmap) OnesCount(start, end uint64) (uint64, error) {

corhere · 2025-08-05T19:01:54Z

daemon/libnetwork/bitmap/sequence.go

+func hiBlockMask(bitPos uint64) uint32 {
+	if bitPos >= uint64(blockLen) {
+		return 0
+	}
+	if bitPos == 0 {
+		return blockFull
+	}
+	return (blockFirstBit >> (bitPos - 1)) - 1
+}


Suggested change

func hiBlockMask(bitPos uint64) uint32 {

if bitPos >= uint64(blockLen) {

return 0

}

if bitPos == 0 {

return blockFull

}

return (blockFirstBit >> (bitPos - 1)) - 1

}

func hiBlockMask(bitPos uint64) uint32 {

return blockFull >> bitPos

}

corhere · 2025-08-05T19:09:36Z

daemon/libnetwork/bitmap/sequence_test.go

+	assert.Check(t, is.Equal(uint32(0xffffffff), loBlockMask(33)))
+}
+
+func TestCalculateSelected(t *testing.T) {


I would trust the implementation a lot more if CalculateSelected was tested by setting up the preconditions through the public interface of bitmap. By directly constructing the sequences it's possible that an incorrect assumption in the code could be carried through to the test cases such that the tests don't catch the bug. This test as written would not catch if you mixed up the bit-endianness of the blocks, for instance.

corhere · 2025-08-05T19:18:11Z

daemon/libnetwork/network.go

+
+	ipamState := map[string]network.IPAMState{}
+	for _, ii := range ipam4Infos {
+		cidr, is, err := defaultipam.GetIPAMStateForPoolID(ii.PoolID, ipam)


Why is generic libnetwork code for any network calling a function from the default IPAM driver? What happens if the IPAM driver for the network is not defaultipam?

corhere · 2025-08-05T19:21:48Z

go.mod


 replace github.com/moby/moby/client => ./client
+
+replace github.com/moby/swarmkit/v2 v2.0.0 => github.com/aepifanov/swarmkit/v2 v2.0.0-20250805114649-a1269cd7a2a8


We can't merge this PR with the Swarmkit dependency replaced with your fork. Please convert this PR to draft.

corhere · 2025-08-07T16:00:24Z

daemon/cluster/convert/network.go

+				if env.Version > 1 && env.Data != nil {
+					log.G(context.TODO()).WithError(err).Warnf("Try to unmarshal it anyway since the version is higher %d than supported %d and might be backward compatible for network %s", env.Version, 1, n.ID)
+					if err := json.Unmarshal(env.Data, netState); err != nil {
+						log.G(context.TODO()).WithError(err).Warnf("Failed to unmarshal network state for network %s", n.ID)
+					}
+				}


What's the point of versioning the type if you're just going to proceed anyway? Why would we bump the version if it's backwards-compatible with v1? And if the type is not backwards-compatible, it's a different data type by definition, so changing the type name would be the more appropriate action than bumping the version.

corhere · 2025-08-07T16:09:19Z

daemon/cluster/convert/network.go

+	netState := &network.NetworkState{}
+	if n.State != nil {
+		env := network.StringifyEnvelope{}
+		if err := json.Unmarshal(n.State.Value, &env); err != nil {


How does the StringifyEnvelope help to enable us to switch to another codec, e.g. protobuf or msgpack, for the state value in the future? It looks like this will lock us into JSON forever.

corhere · 2025-08-07T16:15:00Z

daemon/cluster/convert/network.go

+		if err := json.Unmarshal(n.State.Value, &env); err != nil {
+			log.G(context.TODO()).WithError(err).Warnf("Failed to unmarshal network state for network %s", n.ID)
+		} else if env.Type != network.NetworkStateType {
+			log.G(context.TODO()).WithError(err).Warnf("network state for network %s has unexpeted message type %s", n.ID, env.Type)


What can we infer about how this manager node relates to the leader when this code path is taken? Is there something actionable we could include in the log message?

corhere · 2025-08-07T16:32:30Z

daemon/libnetwork/cnmallocator/networkallocator.go

+	if len(state.IPAM) != 0 {
+		stringifyState, err := json.Marshal(&state)
+		if err != nil {
+			return errors.Wrapf(err, "failed to marshal network state for network %s", net.ID)
+		}
+		// Marshal the network state to a JSON string and store it in the network's State field.
+		// This allows avoiding further changes to the Swarm API and preserves backward compatibility in future releases.
+		envelopedState := networktypes.StringifyEnvelope{
+			Type:    networktypes.NetworkStateType,
+			Version: 1,
+			Data:    stringifyState,
+		}
+		stringifyEnvelopeState, err := json.Marshal(&envelopedState)
+		if err != nil {
+			return errors.Wrapf(err, "failed to marshal network state for network %s", net.ID)
+		}
+		net.State = &gogotypes.Any{
+			TypeUrl: "types.docker.com/NetworkState",
+			Value:   stringifyEnvelopeState,
+		}
+	}


Please co-locate the marshalling code in the same package as the corresponding unmarshalling code. I recommend putting it in daemon/cluster/convert/network.go, the same file as the unmarshaller and same package as all the other code which converts between Engine and Swarm API types.

corhere · 2025-08-07T16:39:23Z

api/types/network/network.go

 	EnableIPv4 bool                        // EnableIPv4 represents whether IPv4 is enabled
 	EnableIPv6 bool                        // EnableIPv6 represents whether IPv6 is enabled
 	IPAM       IPAM                        // IPAM is the network's IP Address Management
+	State      *NetworkState               `json:",omitempty"` // State represents the state of the network


New fields added to API responses need to be gated on the API version so that people developing clients are forced to set the API version correctly and therefore have their clients fail fast when connecting to incompatible engines. Please modify the API endpoints to clear this field on API versions less than the latest (v1.52)

corhere · 2025-08-07T17:07:40Z

api/types/network/network.go

 	EnableIPv4 bool                        // EnableIPv4 represents whether IPv4 is enabled
 	EnableIPv6 bool                        // EnableIPv6 represents whether IPv6 is enabled
 	IPAM       IPAM                        // IPAM is the network's IP Address Management
+	State      *NetworkState               `json:",omitempty"` // State represents the state of the network


Please update the Swagger spec and API changelog with this addition

Adds a new method: - CalculatedSelected(start, end uint64) (uint64, error) Returns the number of selected bits within the specified bit range (start to end, inclusive). Useful for calculating IP utilization within a given range. Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

Adds the following new methods: - Selected() uint64 Returns the number of selected addresses in the set. - CalculateSelectedInRange(netip.Prefix) (uint64, error) Returns the number of selected addresses in the ip-range. - CalculateSelected() (uint64, error) Returns the number of selected addresses in the set. Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

Adds a new method: - GetAllocatedIPs(nw, ipr netip.Prefix) (allocatedIPsInSubnet, allocatedIPsInPool uint64, err error) Returns the number of addresses allocated in both the subnet and the ip-range pool. Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

Extend network inspection with State object which includes IPAM state with ip utilization details. Add a new method to the Ipam interface: - GetAllocatedIPs(poolID string) (allocatedIPsInSubnet, allocatedIPsInPool uint64, err error) Returns the number of addresses allocated in both the subnet and the ip-range pool. Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

Adds support for inspecting overlay networks with a State object that includes IPAM state and IP utilization details. To enable this, the cnmallocator is extended with a new UpdateNetworkState() method, used in a callback from the Swarm API server to populate IPAM data in the network State object. This State object is passed to the API server as a blob, avoiding further changes to the Swarm API and preserving backward compatibility in future releases. Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com> # Conflicts: # go.mod

Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

corhere · 2025-09-15T18:07:42Z

Superseded by api, daemon: report IPAM status for local-scope networks #50917 and daemon: report IPAM status for Swarm networks #50946

aepifanov force-pushed the dev/ip-utilization/main branch from f523212 to bd0d363 Compare July 18, 2025 22:00

aepifanov mentioned this pull request Jul 18, 2025

Add IP utilization moby/swarmkit#3209

Closed

aepifanov force-pushed the dev/ip-utilization/main branch 4 times, most recently from 458003d to 381897c Compare July 22, 2025 15:47

corhere requested review from akerouanton, corhere and robmry July 22, 2025 17:17

corhere added this to the 29.0.0 milestone Jul 22, 2025

corhere added kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny area/networking/ipam Networking impact/api impact/changelog impact/documentation labels Jul 22, 2025

corhere reviewed Jul 22, 2025

View reviewed changes

aepifanov force-pushed the dev/ip-utilization/main branch 3 times, most recently from c90744c to 9972c42 Compare July 25, 2025 16:07

aepifanov requested a review from corhere July 25, 2025 17:14

corhere requested changes Jul 25, 2025

View reviewed changes

aepifanov force-pushed the dev/ip-utilization/main branch 4 times, most recently from 6f5873e to 391b429 Compare August 4, 2025 12:33

aepifanov force-pushed the dev/ip-utilization/main branch 5 times, most recently from 1369797 to e6bf31d Compare August 5, 2025 12:22

aepifanov requested a review from corhere August 5, 2025 15:10

aepifanov changed the title ~~Implements IP utilization tracking for networks~~ [DNM] Implements IP utilization tracking for networks Aug 5, 2025

corhere reviewed Aug 5, 2025

View reviewed changes

aepifanov force-pushed the dev/ip-utilization/main branch 4 times, most recently from 3be6f3b to e1cbc0e Compare August 7, 2025 13:17

corhere reviewed Aug 7, 2025

View reviewed changes

aepifanov force-pushed the dev/ip-utilization/main branch from e1cbc0e to 4ffa31b Compare August 8, 2025 14:56

aepifanov added 3 commits August 11, 2025 02:23

aepifanov force-pushed the dev/ip-utilization/main branch from 4ffa31b to 9401ebf Compare August 11, 2025 10:07

aepifanov added 6 commits August 11, 2025 03:24

bridge: Add test for ip utilization counters

1cd5bdb

Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

ipvlan: Add test for ip utilization counters

e49c179

Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

macvlan: Add test for ip utilization counters

c036f70

Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

overlay: Add test for ip utilization counters

32d4174

Signed-off-by: Andrey Epifanov <aepifanov@mirantis.com>

aepifanov force-pushed the dev/ip-utilization/main branch from 9401ebf to 32d4174 Compare August 11, 2025 12:00

aepifanov requested a review from corhere August 11, 2025 21:55

thaJeztah mentioned this pull request Aug 23, 2025

manager/controlapi: implement New constructor with functional arguments moby/swarmkit#3211

Closed

corhere mentioned this pull request Sep 5, 2025

api, daemon: report IPAM status for local-scope networks #50917

Merged

corhere closed this Sep 15, 2025

	return uint64(1) << (32 - cidr.Bits()), nil
	return uint64(1) << (cidr.Addr().BitLen() - cidr.Bits()), nil

		// CalculateSelected calculates the number of selected bits in the range [start, end].
		func (h *Bitmap) CalculateSelected(start, end uint64) (uint64, error) {


		replace github.com/moby/moby/client => ./client

		replace github.com/moby/swarmkit/v2 v2.0.0 => github.com/aepifanov/swarmkit/v2 v2.0.0-20250805114649-a1269cd7a2a8

Conversation

aepifanov commented Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

corhere left a comment

Choose a reason for hiding this comment

Uh oh!

aepifanov commented Jul 23, 2025

Uh oh!

corhere commented Jul 23, 2025

Uh oh!

aepifanov commented Jul 23, 2025

Uh oh!

corhere commented Jul 23, 2025

Uh oh!

aepifanov commented Jul 25, 2025

Uh oh!

corhere left a comment

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!

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!

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!

corhere commented Sep 15, 2025

Uh oh!

Reviewers

Assignees

aepifanov commented Jul 18, 2025 •

edited

Loading