feat(wire): create connections in batch by Davidson-Souza · Pull Request #865 · getfloresta/Floresta

Davidson-Souza · 2026-03-02T16:49:19Z

Description and Notes

Sometimes when we initialize new connections, our good addresses table
might not be well populated. This causes our node to attempt the "normal"
addresses — the one we still haven't tried. As a consequence, our node will
need to attempt several addresses before finding a reachable one.

This commit creates connection attempts in batches of 10, so we try
more addresses in a shorter period of time. To make sure we don't
keep too many inflights at the time, I've decreased the connection
timeout time, so only those who reply in a timely manner will be kept.

I've also added a logic to handle_peer_ready to disconnect peers if
we already have MAX_OUTGOING_PEERS.

Finally, I've made the periodic_job that creates new connections no_log, so we stop polluting the terminal.

JoseSK999

Opinionated review

JoseSK999 · 2026-03-02T18:50:02Z

+        let good_peers_count = self.connected_peers();
+        if good_peers_count > T::MAX_OUTGOING_PEERS {
+            debug!(
+                "Already have {} peers, disconnecting peer to avoid blowing up our max of {}",
+                self.peers.len(),
+                T::MAX_OUTGOING_PEERS
+            );
+
+            self.send_to_peer(peer, NodeRequest::Shutdown)?;
+
+            return Ok(());
+        }


Hm I think better to take into account how many peers we could connect to before exceeding the limit BEFORE trying more connections, see next comment

Also, to control excess peers we can disconnect slow peers in IBD and random peers once synced... followup PR I have already done privately

JoseSK999 · 2026-03-02T18:52:18Z

        let connection_kind = ConnectionKind::Regular(required_service);
-        if self.peers.len() < T::MAX_OUTGOING_PEERS {
+        for _ in 0..NEW_CONNECTIONS_BATCH_SIZE {
            self.create_connection(connection_kind)?;
        }


I had this in a private branch, I think makes sense

// How many peers we can connect to without exceeding the limit, if any let peer_capacity = T::MAX_OUTGOING_PEERS.saturating_sub(self.connected_peers()); let connection_kind = ConnectionKind::Regular(required_service); // Try connecting to at most 4 peers (fewer if max capacity would be reached) for _ in 0..peer_capacity.min(MAX_OPEN_CONNECTIONS_BATCH) { self.create_connection(connection_kind)?; }

I've tried this, but for the last connections we basically revert to the older logic. I had some runs where I would create 8/9 connections super quick, and then just hang for dozens of seconds.

Using this logic we can get 10 peers for chain selection pretty quickly.

So you exceed the limit on purpose then you disconnect the exceeded peers. Btw the 8/9 fast connections happens to me on master, idk why it takes longer to get the 10th peer.

So you exceed the limit on purpose then you disconnect the exceeded peers.

Yes! It should not get bigger than 20 tho, because we also abort the connection pretty quickly if they don't respond

Btw the 8/9 fast connections happens to me on master, idk why it takes longer to get the 10th peer.

For me as well, I think it has to do with the address manager getting populated by the addresses received from new connections? It's really weird tho. At least for me it doesn't happen on this PR

JoseSK999 · 2026-03-02T18:53:31Z

+        if self.peers.len() >= T::MAX_OUTGOING_PEERS {
+            return Ok(());
+        }


This then can be removed

Then we will keep connecting and disconnecting peers, I think it's fine

Edit: outside of the feelers logic

JoseSK999 · 2026-03-02T18:55:33Z

+/// How many connections we try at once
+const NEW_CONNECTIONS_BATCH_SIZE: usize = 10;


Since we would sometimes try fewer connections this is more accurate. I think 4 is kinda nice but this is just how I feel

/// The maximum number of connections we try to open in parallel, in `maybe_open_connection`. const MAX_OPEN_CONNECTIONS_BATCH: usize = 4;

Maybe this could be part of NodeContext. Then use 4 for all but ChainSelector?

ACK, what if we used 12 for ChainSelector so that 1-2 failed connections don't make us wait 10 seconds (also a nice multiple of 4). We keep the first 10 peers. Not sure.

JoseSK999 · 2026-03-02T18:56:33Z


 impl NodeContext for ChainSelector {
    const REQUEST_TIMEOUT: u64 = 60; // Ban peers stalling our IBD
-    const TRY_NEW_CONNECTION: u64 = 1; // Try creating connections more aggressively


I would keep this with 4 peers as batch size

I've increased this to make sure we GC the dead peers before attempting a new round. We remove all pending Connects before trying to add more, in order to keep the inflight connections list small

jaoleal

CACK

jaoleal · 2026-03-02T18:59:18Z

+        let good_peers_count = self.connected_peers();
+        if good_peers_count > T::MAX_OUTGOING_PEERS {
+            debug!(
+                "Already have {} peers, disconnecting peer to avoid blowing up our max of {}",


If good_peers_count is the value triggering the log, isnt more accurate for it to be:

debug!( "Already have {good_peers_count} peers, disconnecting peer to avoid blowing up our max of {}", T::MAX_OUTGOING_PEERS );

?

JoseSK999 · 2026-03-02T21:07:07Z


    /// Attempt to open a new connection (if needed) every TRY_NEW_CONNECTION seconds
    const TRY_NEW_CONNECTION: u64 = 10; // 10 seconds



What if we move it here:

/// How long should we wait for a peer to respond our connection request. This shouldn't be /// greater than `TRY_NEW_CONNECTION` in order to clear timed-out requests at the same pace. const CONNECTION_TIMEOUT: u64 = 10;

Good idea! Will do

Davidson-Souza · 2026-03-03T00:24:16Z

Pushed 1571ff6:

Moved NEW_CONNECTIONS_BATCH_SIZE to NodeContext (didn't rename it to MAX_OPEN_CONNECTIONS_BATCH since this is not a max, but a fixed number) @JoseSK999
Changed NEW_CONNECTIONS_BATCH_SIZE to 12 for all but RunningNode, which is 4 @JoseSK999
Decreased TRY_NEW_CONNECTION and CONNECTION_TIMEOUT to 2. Now we start downloading headers almost instantly, even on a fresh run (it's surprisingly stable on my end)
Changed the debug! to use `good_peers_count @jaoleal
Added comment on CONNECTION_TIMEOUT about it's link to TRY_NEW_CONNECTION

JoseSK999 · 2026-03-03T14:34:18Z

Isn't using a NEW_CONNECTIONS_BATCH_SIZE of 12 for SyncNode like killing a fly with a nuke? We only use 10 peers there. I think makes more sense to keep 4 the default and only 12 for ChainSelector.

JoseSK999 · 2026-03-03T15:37:02Z

    ) -> Result<(), WireError> {
        // try to connect with manually added peers
        self.maybe_open_connection_with_added_peers()?;
+        if self.peers.len() >= T::MAX_OUTGOING_PEERS {


Shouldn't we use connected_peers()

Davidson-Souza · 2026-03-03T16:33:20Z

Pushed 96a1d80 with this diff

diff --git a/crates/floresta-wire/src/p2p_wire/node/chain_selector_ctx.rs b/crates/floresta-wire/src/p2p_wire/node/chain_selector_ctx.rs
index 068fe30..1ea730f 100644
--- a/crates/floresta-wire/src/p2p_wire/node/chain_selector_ctx.rs
+++ b/crates/floresta-wire/src/p2p_wire/node/chain_selector_ctx.rs
@@ -140,6 +140,10 @@ pub enum PeerCheck {
 impl NodeContext for ChainSelector {
     const REQUEST_TIMEOUT: u64 = 60; // Ban peers stalling our IBD
 
+    // Since we don't have any peers when this starts, we use a more aggressive batch
+    // size to make sure we get our MAX_OUTGOING_CONNECTIONS ASAP
+    const NEW_CONNECTIONS_BATCH_SIZE: usize = 12;
+
     fn get_required_services(&self) -> ServiceFlags {
         ServiceFlags::NETWORK | service_flags::UTREEXO.into() | service_flags::UTREEXO_FILTER.into()
     }
diff --git a/crates/floresta-wire/src/p2p_wire/node/conn.rs b/crates/floresta-wire/src/p2p_wire/node/conn.rs
index 6d7202a..7fa3e34 100644
--- a/crates/floresta-wire/src/p2p_wire/node/conn.rs
+++ b/crates/floresta-wire/src/p2p_wire/node/conn.rs
@@ -573,7 +573,7 @@ where
     ) -> Result<(), WireError> {
         // try to connect with manually added peers
         self.maybe_open_connection_with_added_peers()?;
-        if self.peers.len() >= T::MAX_OUTGOING_PEERS {
+        if self.connected_peers() >= T::MAX_OUTGOING_PEERS {
             return Ok(());
         }
 
diff --git a/crates/floresta-wire/src/p2p_wire/node/running_ctx.rs b/crates/floresta-wire/src/p2p_wire/node/running_ctx.rs
index e7c91ac..cced16f 100644
--- a/crates/floresta-wire/src/p2p_wire/node/running_ctx.rs
+++ b/crates/floresta-wire/src/p2p_wire/node/running_ctx.rs
@@ -58,10 +58,6 @@ pub struct RunningNode {
 impl NodeContext for RunningNode {
     const REQUEST_TIMEOUT: u64 = 2 * 60;
 
-    // We expect already having several peers after IBD, so we don't need to be too aggressive when
-    // creating new connections
-    const NEW_CONNECTIONS_BATCH_SIZE: usize = 4;
-
     fn get_required_services(&self) -> ServiceFlags {
         ServiceFlags::NETWORK
             | service_flags::UTREEXO.into()
diff --git a/crates/floresta-wire/src/p2p_wire/node_context.rs b/crates/floresta-wire/src/p2p_wire/node_context.rs
index ea3bfe3..224fb5e 100644
--- a/crates/floresta-wire/src/p2p_wire/node_context.rs
+++ b/crates/floresta-wire/src/p2p_wire/node_context.rs
@@ -84,7 +84,7 @@ pub trait NodeContext {
     const MAINTENANCE_TICK: Duration = Duration::from_secs(1);
 
     /// How many connections we try at once
-    const NEW_CONNECTIONS_BATCH_SIZE: usize = 12;
+    const NEW_CONNECTIONS_BATCH_SIZE: usize = 4;
 
     fn get_required_services(&self) -> ServiceFlags {
         ServiceFlags::NETWORK

JoseSK999 · 2026-03-03T16:38:32Z

        periodic_job!(
            self.last_feeler => self.open_feeler_connection(),
            RunningNode::FEELER_INTERVAL,
        );


Missing a no log here?

JoseSK999 · 2026-03-03T16:39:05Z

        periodic_job!(
            self.last_feeler => self.open_feeler_connection(),
            SyncNode::FEELER_INTERVAL,
        );


Davidson-Souza · 2026-03-03T17:05:24Z

There's a problem here: if we addnode when we have all our 10 connections, we will disconnect the added node. If we had #636 it would be trivial to fix, since we would just allow added nodes to bypass our quota check

JoseSK999 · 2026-03-03T17:15:46Z

Righttt, what about a small PR only adding Manual peers, should be easy to review and merge (or even in this PR if it's not that complex to add)

Davidson-Souza · 2026-03-03T18:03:00Z

Righttt, what about a small PR only adding Manual peers, should be easy to review and merge (or even in this PR if it's not that complex to add)

Hold my coffee, will craft one in a jiffy

JoseSK999 · 2026-03-03T18:40:05Z

Holding your cubata

Davidson-Souza · 2026-03-03T21:18:28Z

I've incorporated #866 and it seems to fix #865 (comment). Marking this as draft until #866 gets merged

JoseSK999 · 2026-03-04T13:41:36Z

+                    T::MAX_OUTGOING_PEERS
+                );
+
+                self.send_to_peer(peer, NodeRequest::Shutdown)?;


Note we have just sent a GetAddresses to this node, but then we disconnect. Idk if we will receive the addresses at all, or just disconnect.

A random idea I got: maybe we can convert these excess peers into feeler peers. We get the addresses and then disconnect.

Idk if this is a good idea tho, but at least the excess peers are helpful in this case.

I like the idea, fixed!

Davidson-Souza · 2026-03-06T17:59:34Z

Tor was working fine for me but I guess you have compound latency

Yeah, it was taking a long time to find peers because it kept timing out. Leme try again and see if it was a momentary thing

In getfloresta#793 we reduced the `DNS_SEED_REQUEST_INTERVAL` to two minutes. This tells how long do we wait before re-doing a request do the DNS seeds. The goal was to make sure we had enough peers to keep going. However, it doesn't seem like it worked as intended since DNS servers are currently bad at giving utreexo peers (and on signet they are also bad at giving CBS peers). This forces our node to retry DNS requests every two minutes. But since most users don't have their own recursive resolver (I don't), the previous result is almost always cached, so you get basically the same answer several times. This pollutes stdout for no good reason. Since getfloresta#781 we now are super aggressive about asking for addresses and checking whether they are alive and learning about their capabilities and getfloresta#865 will make it even better, since we can try several feeler connections at the same time. So I think DNS seeds should be only used to get us some starting peers, and then we build our local network view from the P2P net ourselves.

JoseSK999 · 2026-03-06T20:20:31Z

Did you see #865 (comment)

In getfloresta#793 we reduced the `DNS_SEED_REQUEST_INTERVAL` to two minutes. This tells how long do we wait before re-doing a request do the DNS seeds. The goal was to make sure we had enough peers to keep going. However, it doesn't seem like it worked as intended since DNS servers are currently bad at giving utreexo peers (and on signet they are also bad at giving CBS peers). This forces our node to retry DNS requests every two minutes. But since most users don't have their own recursive resolver (I don't), the previous result is almost always cached, so you get basically the same answer several times. This pollutes stdout for no good reason. Since getfloresta#781 we now are super aggressive about asking for addresses and checking whether they are alive and learning about their capabilities and getfloresta#865 will make it even better, since we can try several feeler connections at the same time. So I think DNS seeds should be only used to get us some starting peers, and then we build our local network view from the P2P net ourselves.

0ceeb59 chore(wire): increase the dns seed grace period time (Davidson Souza) Pull request description: ### Description and Notes In #793 we reduced the `DNS_SEED_REQUEST_INTERVAL` to two minutes. This tells how long do we wait before re-doing a request do the DNS seeds. The goal was to make sure we had enough peers to keep going. However, it doesn't seem like it worked as intended since DNS servers are currently bad at giving utreexo peers (and on signet they are also bad at giving CBS peers). This forces our node to retry DNS requests every two minutes. But since most users don't have their own recursive resolver (I don't), the previous result is almost always cached, so you get basically the same answer several times. This pollutes stdout for no good reason. Since #781 we now are super aggressive about asking for addresses and checking whether they are alive and learning about their capabilities and #865 will make it even better, since we can try several feeler connections at the same time. So I think DNS seeds should be only used to get us some starting peers, and then we build our local network view from the P2P net ourselves. ACKs for top commit: luisschwab: ACK 0ceeb59 JoseSK999: ACK 0ceeb59 Tree-SHA512: a3529e147ca18ba18eab7b59918b17521a70addf9de7c37750612e58b6aea9f3173869672454126f516b2e38bd3d7f597d5e3731b850d2b86201982b8e14eae7

jaoleal

Just some doc nits

jaoleal · 2026-03-10T16:22:03Z

    const REQUEST_TIMEOUT: u64 = 60; // Ban peers stalling our IBD
-    const TRY_NEW_CONNECTION: u64 = 1; // Try creating connections more aggressively
+
+    // Since we don't have any peers when this starts, we use a more aggressive batch


Suggested change

// Since we don't have any peers when this starts, we use a more aggressive batch

// Since we don't have any peers when chain selection starts, we use a more aggressive batch

jaoleal · 2026-03-10T16:22:27Z

-    const TRY_NEW_CONNECTION: u64 = 1; // Try creating connections more aggressively
+
+    // Since we don't have any peers when this starts, we use a more aggressive batch
+    // size to make sure we get our MAX_OUTGOING_CONNECTIONS ASAP


Suggested change

// size to make sure we get our MAX_OUTGOING_CONNECTIONS ASAP

// size to make sure we get to our `MAX_OUTGOING_CONNECTIONS` ASAP

Davidson-Souza · 2026-03-10T17:36:45Z

Pushed dcf2442 addressing @jaoleal's suggestion.

jaoleal · 2026-03-10T17:46:38Z

ACK dcf2442

JoseSK999 · 2026-03-10T19:16:23Z

+                    T::MAX_OUTGOING_PEERS
+                );
+
+                // If a peer exceeds our max, just turn then into a feeler so we can receive their


Suggested change

// If a peer exceeds our max, just turn then into a feeler so we can receive their

// If a peer exceeds our max, just turn them into a feeler so we can receive their

JoseSK999 · 2026-03-10T19:17:13Z

+                self.peers
+                    .entry(peer)
+                    .and_modify(|peer| peer.kind = ConnectionKind::Feeler);


Nit: I like this style

Suggested change

self.peers

.entry(peer)

.and_modify(|peer| peer.kind = ConnectionKind::Feeler);

self.peers.entry(peer).and_modify(|p| {

p.kind = ConnectionKind::Feeler;

});

Sometimes when we initialize new connections, our `good addresses` table might not be well populated. This causes our node to attempt the "normal" addresses — the one we still haven't tried. As a consequence, our node will need to attempt several addresses before finding a reachable one. This commit creates connection attempts in batches of 10, so we try more addresses in a shorter period of time. To make sure we don't keep too many inflights at the time, I've decreased the connection timeout time, so only those who reply in a timely manner will be kept. I've also added a logic to `handle_peer_ready` to disconnect peers if we already have MAX_OUTGOING_PEERS.

When we use `periodic_jobs` with `maybe_create_connections` we might create a lot of `NoAddressAvailable` errors, specially on signet/testnet/regtest. This offers little information and pollutes the terminal. This commit uses the no_log attribute from `periodic_job` to avoid logging errors to stdout

Davidson-Souza · 2026-03-10T20:07:58Z

Pushed 4f558c6 with minor docs fixes

jaoleal · 2026-03-10T20:10:00Z

ACK 4f558c6

JoseSK999 · 2026-03-10T20:45:13Z

I am getting UtreexoError("Missing sibling for 4270") from utreexod:0.5.0

JoseSK999

ACK 4f558c6

Davidson-Souza · 2026-03-10T20:46:54Z

I am getting UtreexoError("Missing sibling for 4270") from utreexod:0.5.0

Yes, this is expected! pushing the new numbering scheme soon

JoseSK999 · 2026-03-10T20:50:00Z

So we are banning everyone right now 😂 lesgoo

This commit reduces the interval between connection attempts to 10 secods (the default for NodeContext) and don't try to create a normal connection if we are short on utreexo ones. The latter change is important if you consider the logic to avoid having too many connections added in getfloresta#865. If the non-utreexo peer responds first, and we have nine connections, they will take the tenth position. When the utreexo node responds, they will be consider an excess node and get disconnected. One side-effect of this is in cases where we struggle to make utreexo connections and lose some regurlar connections. We might have a very small number of regular peers as well. This is why we have a bypass if our peer count is too low.

Davidson-Souza self-assigned this Mar 2, 2026

Davidson-Souza added enhancement New feature or request performance This is a performance-related issue labels Mar 2, 2026

Davidson-Souza force-pushed the feature/connection-batch branch from 898303b to 1db21e3 Compare March 2, 2026 16:50

JoseSK999 reviewed Mar 2, 2026

View reviewed changes

Davidson-Souza changed the title ~~Feature/connection batch~~ feat(wire): create connections in batch Mar 2, 2026

jaoleal approved these changes Mar 2, 2026

View reviewed changes

jaoleal mentioned this pull request Mar 2, 2026

fix(wire): Dont error when no conections while on regtest. #791

Closed

3 tasks

JoseSK999 reviewed Mar 2, 2026

View reviewed changes

Davidson-Souza force-pushed the feature/connection-batch branch 2 times, most recently from 1571ff6 to e991a0f Compare March 3, 2026 00:21

JoseSK999 reviewed Mar 3, 2026

View reviewed changes

Davidson-Souza force-pushed the feature/connection-batch branch from e991a0f to 96a1d80 Compare March 3, 2026 16:31

JoseSK999 reviewed Mar 3, 2026

View reviewed changes

Davidson-Souza mentioned this pull request Mar 3, 2026

fix: invalidate blocks with invalid transactions, and ban bad/malicious utreexo peers #852

Merged

This was referenced Mar 3, 2026

Feat: add Manual type to ConnectionKinds #866

Merged

0.9.0 priorities #850

Closed

Davidson-Souza added this to the v0.9.0 milestone Mar 3, 2026

Davidson-Souza force-pushed the feature/connection-batch branch from 96a1d80 to 4ce49a7 Compare March 3, 2026 21:17

Davidson-Souza marked this pull request as draft March 3, 2026 21:17

JoseSK999 reviewed Mar 4, 2026

View reviewed changes

Davidson-Souza force-pushed the feature/connection-batch branch from 2a3591b to a42e903 Compare March 10, 2026 15:44

jaoleal approved these changes Mar 10, 2026

View reviewed changes

Davidson-Souza force-pushed the feature/connection-batch branch from a42e903 to dcf2442 Compare March 10, 2026 17:35

luisschwab self-requested a review March 10, 2026 17:53

jaoleal requested a review from JoseSK999 March 10, 2026 18:00

JoseSK999 reviewed Mar 10, 2026

View reviewed changes

Davidson-Souza added 2 commits March 10, 2026 17:05

Davidson-Souza force-pushed the feature/connection-batch branch from dcf2442 to 4f558c6 Compare March 10, 2026 20:05

Davidson-Souza requested review from JoseSK999 and jaoleal March 10, 2026 20:08

JoseSK999 approved these changes Mar 10, 2026

View reviewed changes

Davidson-Souza merged commit 023f72d into getfloresta:master Mar 10, 2026
11 checks passed

csgui added this to Floresta Mar 12, 2026

csgui moved this to Done in Floresta Mar 12, 2026

csgui added the reliability Related to runtime reliability, stability and production readiness label Mar 12, 2026

		/// How many connections we try at once
		const NEW_CONNECTIONS_BATCH_SIZE: usize = 10;


		/// Attempt to open a new connection (if needed) every TRY_NEW_CONNECTION seconds
		const TRY_NEW_CONNECTION: u64 = 10; // 10 seconds

	// Since we don't have any peers when this starts, we use a more aggressive batch
	// Since we don't have any peers when chain selection starts, we use a more aggressive batch

	// size to make sure we get our MAX_OUTGOING_CONNECTIONS ASAP
	// size to make sure we get to our `MAX_OUTGOING_CONNECTIONS` ASAP

	// If a peer exceeds our max, just turn then into a feeler so we can receive their
	// If a peer exceeds our max, just turn them into a feeler so we can receive their

Uh oh!

Conversation

Davidson-Souza commented Mar 2, 2026

Description and Notes

Uh oh!

JoseSK999 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!

Davidson-Souza Mar 2, 2026 • 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!

Davidson-Souza Mar 3, 2026 • 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!

JoseSK999 Mar 2, 2026 • 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!

jaoleal 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!

Davidson-Souza commented Mar 3, 2026

Uh oh!

JoseSK999 commented Mar 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Davidson-Souza commented Mar 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Davidson-Souza commented Mar 3, 2026

Uh oh!

JoseSK999 commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Davidson-Souza commented Mar 3, 2026

Uh oh!

JoseSK999 commented Mar 3, 2026

Uh oh!

Davidson-Souza commented Mar 3, 2026

Uh oh!

JoseSK999 Mar 4, 2026 • 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!

Davidson-Souza Mar 2, 2026 •

edited

Loading

Davidson-Souza Mar 3, 2026 •

edited

Loading

JoseSK999 Mar 2, 2026 •

edited

Loading

JoseSK999 commented Mar 3, 2026 •

edited

Loading

JoseSK999 Mar 4, 2026 •

edited

Loading

Davidson-Souza commented Mar 10, 2026 •

edited

Loading