feat: chain orchestrator #185

frisitano · 2025-07-02T19:06:49Z

closes: #182
closes scroll-tech/reth#243

Copilot

Pull Request Overview

This PR implements a new ChainOrchestrator to replace the previous indexer, integrates it throughout the node, watcher, network, and engine, and updates tests and database migrations accordingly.

Introduces ChainOrchestrator in place of Indexer, refactors RollupNodeManager to consume orchestrator events instead of indexer events.
Adds Synced notifications to L1Watcher and updates engine driver to handle optimistic sync via ChainOrchestrator.
Refactors configuration (ScrollRollupNodeConfig), network manager, and database migrations; adjusts tests to cover the new orchestrator flows.

Reviewed Changes

Copilot reviewed 40 out of 41 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
crates/indexer/src/lib.rs	Rename `Indexer` to `ChainOrchestrator` and overhaul API flows
crates/manager/src/manager/mod.rs	Replace indexer usage with `ChainOrchestrator` in node manager
crates/node/src/args.rs	Instantiate `ChainOrchestrator` in `ScrollRollupNodeConfig`
crates/watcher/src/lib.rs	Add `Synced` variant and `is_synced` flag to `L1Watcher`
crates/scroll-wire/src/protocol/proto.rs	Adjust doc comment for `NewBlock::new`
crates/node/tests/e2e.rs	Add/revise reorg and sync end-to-end tests
crates/watcher/tests/reorg.rs	Update tests to skip `Synced` notifications
crates/database/db/src/operations.rs	Extend DB ops with `L1MessageStart` and block-and-batch queries
crates/database/migration/src/migration_info.rs	Add `genesis_hash()` to migrations and insert genesis blocks
crates/network/src/manager.rs	Wire up eth-wire listener and dispatch chain-orchestrator events
crates/engine/src/driver.rs	Support `ChainImport` and `OptimisticSync` futures in engine driver

Comments suppressed due to low confidence (2)

crates/scroll-wire/src/protocol/proto.rs:33

The doc comment uses "blocks" (plural) but the constructor takes a single block; change to "block" for accuracy.

    /// Returns a [`NewBlock`] instance with the provided signature and blocks.

crates/node/tests/e2e.rs:95

The follower_can_reorg test has no assertions; either add meaningful checks or remove the empty test to maintain coverage.

async fn follower_can_reorg() -> eyre::Result<()> {

crates/watcher/tests/reorg.rs

greged93

Couple of comments and some small nits and leftover code to clean.

.github/workflows/test.yaml

crates/chain-orchestrator/src/metrics.rs

crates/chain-orchestrator/src/lib.rs

crates/node/tests/sync.rs

crates/sequencer/tests/e2e.rs

greged93 · 2025-07-23T15:35:20Z

crates/watcher/src/lib.rs

-            if self.is_synced() {
+            if self.is_synced {
                tokio::time::sleep(SLOW_SYNC_INTERVAL).await;
+            } else if self.current_block_number == self.l1_state.head {
+                // if we have synced to the head of the L1, notify the channel and set the
+                // `is_synced`` flag.
+                if let Err(L1WatcherError::SendError(_)) = self.notify(L1Notification::Synced).await
+                {
+                    tracing::warn!(target: "scroll::watcher", "L1 watcher channel closed, stopping the watcher");
+                    break;
+                }
+                self.is_synced = true;


the current logic suggests the watcher can never transition from is_synced = true -> false. Is this expected?

Good question. In the context of the RN, Synced should mean that we have synced all L1 messages required to validate messages included in unsafe L2 blocks. Given that we only include L1 messages after the corresponding L1 block has been finalized I think this should be fine provided the watcher doesn't start to lag > 2 epochs behind the safe tip then the Synced status should still remain valid. What do you think about this?

hmmm but so if we lose a provider for 12 minutes we might enter an edge case we can't exit from?

good point and given that we have had recent experiences of the L1 provider being down for longer than 12 minutes I think we should cover this case.

Should we do this in another PR?

Agree let's address this in another PR

@jonastheis is it fair to say this is captured in this issue #252?

greged93

couple of extra comments and questions. Also I see we have a lot more unwraps in the code, are all these safe to keep?

greged93 · 2025-08-03T15:25:58Z

crates/chain-orchestrator/src/lib.rs

+        // Reverse the new chain headers to have them in the correct order.
+        received_chain_headers.reverse();


Personally think we would gain in code clarity if received_chain_headers and current_chain_headers were ordered in the same way.

I would tend to agree but I think we should attempt to merge as is for now and then refactor this at a later date.

works for me, should we raise an issue with all improvements listed?

crates/chain-orchestrator/src/lib.rs

greged93 · 2025-08-03T15:41:50Z

crates/engine/src/driver.rs

+        // Purge all pending block imports.
+        self.chain_imports.clear();


why do we purge all pending block imports?

Because the optimistic sync supercedes any previous chain imports. Does this seem reasonable to you?

should we also clear the pending futures then?

I presume you are referring to engine_future? If so, we could do but this engine future may be related to an L1 consolidation, in which case we wouldn't want to clear it. I think it's fine to leave as unless I'm missing something?

crates/network/src/manager.rs

crates/sequencer/tests/e2e.rs

greged93

reviewing l2geth code, I noticed we might be missing checks on L1 messages.

greged93 · 2025-08-07T10:17:51Z

crates/chain-orchestrator/src/lib.rs

+async fn validate_l1_messages(
+    blocks: &[ScrollBlock],
+    database: Arc<Database>,
+) -> Result<(), ChainOrchestratorError> {


I think we might be missing a couple of checks in this function:
https://github.com/scroll-tech/go-ethereum/blob/develop/core/block_validator.go#L104-L109

Post Euclid V2: check indexes are continuous, at the start of the block and start at the last seen L1 message index.

Pre Euclid V2: queue index can't decrease, check skipped L1 messages are in DB.

I think we can omit the check on queue indexes not being decreasing for now, as we will (most likely?) never sync pre euclid v2 blocks via live sync. I will open an issue to track this and we can implement it in the future to support pre euclid v2 sync.

Regarding the start index, how about we introduce an l1_message_index: Arc<Mutex<IndexType> in memory which is used to determine the cursor start. I think continuity is already covered due to the fact that we assert consistency with the db? Regarding the position in the block I will implement a check for that as well.

Or are you suggesting we do this in the consensus on reth (as I believe you have already in the open PR)?

Or are you suggesting we do this in the consensus on reth (as I believe you have already in the open PR)?

I'm actually not sure if we should have these checks in Reth and/or Rollup node. What do you think?

Regarding the start index, how about we introduce an l1_message_index: Arc<Mutex in memory which is used to determine the cursor start.

Won't we have an issue with L1 reorgs with this?

I'm actually not sure if we should have these checks in Reth and/or Rollup node. What do you think?

I think it makes sense to have the L1 message checks in the rollup node.

Won't we have an issue with L1 reorgs with this?

I wouldn't have thought so because L1 messages are only included when they are finalized, right?

I think it makes sense to have the L1 message checks in the rollup node.

Works for me. I think I will still leave the current ones in Reth, for historical sync in order to still have a minimal check wdyt?

I wouldn't have thought so because L1 messages are only included when they are finalized, right?

As long as the sequencer uses the L1MessageInclusionMode::Finalized I think that's fine but if we switch to BlockDepth we might start to have issues.

We should replicate the l2geth implementation as close as possible. This also means the order within the block etc. We should open a separate issue to revisit this after the PR is merged.

greged93

just need to resolve the pending comments and open 1 issues related to L1 watcher sync.

jonastheis · 2025-08-18T11:08:29Z

crates/chain-orchestrator/src/event.rs

+    /// A `BatchCommit` event has been indexed returning the batch info and the L2 block info to
+    /// revert to due to a batch revert.


I don't understand this comment

jonastheis · 2025-08-18T11:11:08Z

crates/chain-orchestrator/src/event.rs

+    /// The chain has been unwound, returning the L1 block number of the new L1 head,
+    /// the L1 message queue index of the new L1 head, and optionally the L2 head and safe block
+    /// info if the unwind resulted in a new L2 head or safe block.
+    ChainUnwound {


Not sure what does this mean? Is it a reorg?

jonastheis · 2025-08-18T11:12:16Z

crates/chain-orchestrator/src/event.rs

Naming on the events seems a bit inconsistent after just reading the event names and description in this file.

jonastheis · 2025-08-18T11:17:54Z

crates/database/migration/src/migration_info.rs

@@ -18,6 +20,11 @@ impl MigrationInfo for () {
    fn data_hash() -> Option<B256> {
        None
    }
+
+    fn genesis_hash() -> B256 {
+        // Todo: Update


Update to which value?

I think this blanket implementation is improper (impl MigrationInfo for ()) I will replace it with impl MigrationInfo for ScrollDevMigrationInfo, and then this is no longer relevant. When we want to support custom chain specs, we will have to revisit this issue as the genesis_hash will no longer be static.

jonastheis · 2025-08-18T11:34:38Z

crates/node/src/args.rs

 /// The network arguments.
 #[derive(Debug, Clone, clap::Args)]
 pub struct NetworkArgs {
    /// A bool to represent if new blocks should be bridged from the eth wire protocol to the
    /// scroll wire protocol.
-    #[arg(long = "network.bridge", default_value_t = true)]
+    #[arg(long = "network.bridge")]


Why removing the default value here?

Currently, there is no way to set this to false via CLI. With booleans, the absence of the argument represents false. However, because we are setting default_value_t = true, this remains true even in the absence of the CLI argument.

jonastheis · 2025-08-18T11:35:01Z

crates/node/src/args.rs

    pub enable_eth_scroll_wire_bridge: bool,
    /// A bool that represents if the scroll wire protocol should be enabled.
-    #[arg(long = "network.scroll-wire", default_value_t = true)]
+    #[arg(long = "network.scroll-wire")]


Why removing the default value here?

Currently, there is no way to set this to false via CLI. With booleans, the absence of the argument represents false. However, because we are setting default_value_t = true, this remains true even in the absence of the CLI argument.

jonastheis · 2025-08-18T11:35:34Z

crates/node/src/args.rs

@@ -422,11 +469,19 @@ pub struct NetworkArgs {
        value_name = "NETWORK_SEQUENCER_URL"
    )]
    pub sequencer_url: Option<String>,
+    /// A bool that represents if blocks should be gossiped over the eth-wire protocol.
+    #[arg(long = "network.eth-wire-gossip")]


How does this interact with enable_eth_scroll_wire_bridge?

enable_eth_scroll_wire_bridge is for incoming blocks?

eth-wire-gossip for outgoing? Shouldn't this be enabled by default as well until we deprecate l2geth?

Your description of the interaction is correct.

The intention of this flag was to mitigate duplication of block announcements. However, I think a more robust solution would be to handle it on the receiving end as described in your issue #251. I will revert this change.

jonastheis · 2025-08-18T11:48:20Z

crates/network/src/manager.rs

+        {
+            Some(NetworkManagerEvent::NewBlock(NewBlockWithPeer { peer_id, block, signature }))
+        } else {
+            tracing::warn!(target: "scroll::bridge::import", peer_id = %peer_id, "Failed to extract signature from block extra data");


Shouldn't we penalize the peer here that sent us the block without the signature on eth wire? This is an invalid message for both l2geth and reth no?

Good catch yes we should. will update.

jonastheis · 2025-08-18T12:01:14Z

crates/manager/src/manager/mod.rs

+                        outcome.chain.iter().map(|b| b.into()).collect(),
+                    );
+                }
+                self.network.handle().block_import_outcome(outcome.outcome);


Does this mean we might announce these blocks even if they are relatively old?

If it is an old block (i.e. a block we have already seen it) then we will not attempt a block import and the chain orchestrator will return the event BlockAlreadyKnown. We will only attempt to import blocks that we have not already seen before (i.e. new blocks).

jonastheis · 2025-08-18T12:03:00Z

crates/manager/src/manager/mod.rs

                Err(err) => {
-                    error!(target: "scroll::node::manager", ?err, "Error occurred at indexer level")
+                    match &err {


wouldn't this be better handled in a function as well?

jonastheis · 2025-08-19T01:57:37Z

crates/database/db/src/models/l2_block.rs

@@ -9,21 +9,17 @@ pub struct Model {
    #[sea_orm(primary_key)]
    block_number: i64,
    block_hash: Vec<u8>,
-    batch_index: Option<i64>,
-    batch_hash: Option<Vec<u8>>,
+    batch_index: i64,


Why remove the option here? What's this value for unsafe L2 blocks?

We don't persist unsafe L2 blocks in the database anymore. They are already persisted in the execution node.

jonastheis · 2025-08-19T02:02:57Z

crates/scroll-wire/src/protocol/proto.rs

@@ -30,7 +30,7 @@ pub struct NewBlock {
 }

 impl NewBlock {
-    /// Returns a [`NewBlock`] instance with the provided signature and block.
+    /// Returns a [`NewBlock`] instance with the provided signature and blocks.


jonastheis · 2025-08-19T02:15:26Z

crates/watcher/src/lib.rs

-            if self.is_synced() {
+            if self.is_synced {
                tokio::time::sleep(SLOW_SYNC_INTERVAL).await;
+            } else if self.current_block_number == self.l1_state.head {
+                // if we have synced to the head of the L1, notify the channel and set the
+                // `is_synced`` flag.
+                if let Err(L1WatcherError::SendError(_)) = self.notify(L1Notification::Synced).await
+                {
+                    tracing::warn!(target: "scroll::watcher", "L1 watcher channel closed, stopping the watcher");
+                    break;
+                }
+                self.is_synced = true;


Agree let's address this in another PR

jonastheis · 2025-08-19T02:27:33Z

crates/engine/src/driver.rs

-            self.syncing = true
-        }
+    pub fn handle_chain_import(&mut self, chain_import: ChainImport) {
+        tracing::trace!(target: "scroll::engine", head = %chain_import.chain.last().unwrap().hash_slow(), "new block import request received");


Suggested change

tracing::trace!(target: "scroll::engine", head = %chain_import.chain.last().unwrap().hash_slow(), "new block import request received");

tracing::trace!(target: "scroll::engine", head = %chain_import.chain.last().unwrap().hash_slow(), "new chain import request received");

also update the comment of the function

jonastheis · 2025-08-19T05:46:06Z

crates/chain-orchestrator/src/lib.rs

+                let parent_hash =
+                    optimistic_headers.first().expect("chain can not be empty").parent_hash;
+                let header = network_client
+                    .get_header(BlockHashOrNumber::Hash(parent_hash))


This will request up to 2000 headers (by default == CHAIN_BUFFER_SIZE) one by one from other nodes. Is this efficient? Shoudldn't we use GetBlockHeaders for this? Or why request the headers at all? We could also wait for the EN to finish the sync and then load from our EN?

Is this efficient? Shouldn't we use GetBlockHeaders for this?

Yes, a more efficient means would be to use GetBlockHeaders.

We could also wait for the EN to finish the sync and then load from our EN?

I think this is the best solution.

I will add both of these points to the refactoring issue that I create shortly.

jonastheis · 2025-08-19T05:53:33Z

crates/chain-orchestrator/src/lib.rs

+        // Check if we have already have this block in memory.
+        if received_block.number <= max_block_number &&
+            received_block.number >= min_block_number &&
+            current_chain_headers.iter().any(|h| h == &received_block.header)


How expensive is this? Do we expect this to become a bottleneck with high throughput?

I think we can improve the implementation to be much more efficient by leveraging the EN. I think we can completely eliminate the in-memory buffer which should make this solution much more efficient. I will write this up in the issue.

jonastheis · 2025-08-19T06:13:17Z

crates/chain-orchestrator/src/lib.rs

+                    }
+                    tracing::trace!(target: "scroll::chain_orchestrator", number = ?(current_chain_headers.front().expect("chain can not be empty").number - 1), "fetching block for current chain");
+                    if let Some(block) = l2_client
+                        .get_block_by_hash(


What's the timeout for this operation? What if none of our neighbors supplies this block?

If neighbours do not supply the block, we will raise an error and reject the block we are trying to import.

jonastheis · 2025-08-19T06:15:30Z

crates/node/src/constants.rs

+pub(crate) const BLOCK_GAP_TRIGGER: u64 = 100_000;
+
+/// The number of block headers to keep in the in-memory chain buffer in the chain orchestrator.
+pub(crate) const CHAIN_BUFFER_SIZE: usize = 2000;


Wondering if 2000 is enough? How much memory would this occupy?

I think we can increase this considerably if required. The general idea is that we should keep enough blocks in memory to support reorgs. I was thinking that a reorg of > 2000 blocks is unlikely.

jonastheis · 2025-08-19T06:23:49Z

crates/chain-orchestrator/src/lib.rs

+                h.hash_slow() ==
+                    received_chain_headers.last().expect("chain can not be empty").parent_hash
+            }) {
+                // If the received fork is older than the current chain, we return an event


How do we know here that this is a fork/reorg?

Because the received chain does not extend the current chain head (pos < current_chain_headers.len() - 1) it extends from a deeper block.

jonastheis · 2025-08-19T06:24:48Z

crates/chain-orchestrator/src/lib.rs

+
+            // If the current header block number is less than the latest safe block number then
+            // we should error.
+            if received_chain_headers.last().expect("chain can not be empty").number <=


Shouldn't we do this quick check already earlier?

yes, I've moved the check higher.

jonastheis · 2025-08-19T06:26:06Z

crates/chain-orchestrator/src/lib.rs

+                return Err(ChainOrchestratorError::L2SafeBlockReorgDetected);
+            }
+
+            tracing::trace!(target: "scroll::chain_orchestrator", number = ?(received_chain_headers.last().expect("chain can not be empty").number - 1), "fetching block");


can't we store received_chain_headers.last() in a variable somewhere to avoid calling the expect dozens of times?

jonastheis · 2025-08-19T06:32:48Z

crates/chain-orchestrator/src/lib.rs

+                // If the received fork is older than the current chain, we return an event
+                // indicating that we have received an old fork.
+                if (pos < current_chain_headers.len() - 1) &&
+                    current_chain_headers.get(pos + 1).expect("chain can not be empty").timestamp >


This seems like quite important: we don't react to reorgs based on timestamp of a block. what if the sequencer's time is faulty?

Agree that this is important. What do you think the rule should be?

jonastheis · 2025-08-19T09:31:38Z

crates/chain-orchestrator/src/lib.rs

+
+/// Consolidates the chain by reconciling the in-memory chain with the L2 client and database.
+/// This is used to ensure that the in-memory chain is consistent with the L2 chain.
+async fn consolidate_chain<P: Provider<Scroll> + 'static>(


Why is it enough to consolidate only back to the safe head? Is it because the safe block is derived from L1 and the L1 messages until that point are verified through the L1 derivation pipeline?

jonastheis · 2025-08-20T00:05:13Z

crates/chain-orchestrator/src/lib.rs

+
+        let queue_hash = if chain_spec
+            .scroll_fork_activation(ScrollHardfork::EuclidV2)
+            .active_at_timestamp_or_number(block_timestamp, l1_block_number) &&


Why pass l1_block_number here? Isn't this L2 fork rules and L1 block info? We might need to check this based on L1MessageQueueV2DeploymentBlock which is an L1 block height. But even this one I'm not sure. As the actual transition on L1 happened after that.

jonastheis · 2025-08-20T00:14:57Z

crates/chain-orchestrator/src/lib.rs

+        let event = ChainOrchestratorEvent::BatchCommitIndexed {
+            batch_info: BatchInfo::new(batch.index, batch.hash),
+            l1_block_number: batch.block_number,
+            safe_head: new_safe_head,


Why is the safe_head only part of this event in case there was a batch revert? Couldn't it always be part of the event and have a separate field if it was indeed a batch revert (if we even need that information)?

jonastheis · 2025-08-20T00:16:23Z

crates/chain-orchestrator/src/lib.rs

+    }
+
+    /// Returns the highest finalized block for the provided batch hash. Will return [`None`] if the
+    /// block number has already been seen by the indexer.


Let's also update the comments where indexer -> chain orchestrator

jonastheis · 2025-08-20T00:24:32Z

crates/chain-orchestrator/src/lib.rs

+async fn validate_l1_messages(
+    blocks: &[ScrollBlock],
+    database: Arc<Database>,
+) -> Result<(), ChainOrchestratorError> {


We should replicate the l2geth implementation as close as possible. This also means the order within the block etc. We should open a separate issue to revisit this after the PR is merged.

frisitano added 12 commits July 2, 2025 19:44

feat: chain orchestrator

c1e5cc2

Merge branch 'main' into feat/chain-orchestrator

bbe0e8f

lint

4032fa5

lint

39802e2

docs lint

c84dc0d

fix: clone the in-memory chain instead of taking it

ea3140c

Merge branch 'main' into feat/chain-orchestrator

a28a5b2

update chain consolidation and l1 message validation

fa6952c

add missing network block error

43cc2be

update fork sync / reconcilliation to use network as opossed to database

5dfc813

Merge branch 'main' into feat/chain-orchestrator

a50558d

fix merege

19458f7

frisitano mentioned this pull request Jul 15, 2025

[ChainOrchestrator] Monitor performance of recursive syncing of blocks #199

Open

frisitano added 2 commits July 16, 2025 12:56

refactor and add test cases

4578d49

cleanup

e6248f5

frisitano marked this pull request as ready for review July 16, 2025 14:10

Merge branch 'main' into feat/chain-orchestrator

626e29b

frisitano requested a review from Copilot July 16, 2025 14:13

Copilot AI reviewed Jul 16, 2025

View reviewed changes

crates/watcher/tests/reorg.rs Show resolved Hide resolved

frisitano added 2 commits July 16, 2025 22:21

rename chain orchestrator crate

7a6ebfc

cleanup

7d35185

frisitano requested a review from greged93 July 17, 2025 17:14

frisitano added 7 commits July 18, 2025 18:36

Merge branch 'main' into feat/chain-orchestrator

74fd7b8

remove expect for sequencer in rnm

fe75ed5

sync test

f3bab0d

sync test

56a0ff3

sync test

1320f14

add error handling for missing paylaod id

0fa87fe

remove networking for L1 consolidation sync test

cecbd03

greged93 mentioned this pull request Jul 22, 2025

feat: bump reth #211

Merged

greged93 reviewed Jul 23, 2025

View reviewed changes

frisitano added 7 commits July 30, 2025 01:58

Merge branch 'main' into feat/chain-orchestrator

af4bac9

improve test coverage and fix bugs

7df1a59

lint

fa51172

fix cli NetworkArgs

e86446d

add block gap to reorg integration test

9cdbdf3

Merge branch 'main' into feat/chain-orchestrator

01a10cf

make test more robust

2f851b1

greged93 reviewed Aug 3, 2025

View reviewed changes

greged93 mentioned this pull request Aug 5, 2025

L1 message validation scroll-tech/reth#243

Open

frisitano added 2 commits August 7, 2025 00:48

Merge branch 'main' into feat/chain-orchestrator

9f88b5d

merge upstream

9a3339a

greged93 reviewed Aug 7, 2025

View reviewed changes

refactor

000ade7

This was referenced Aug 11, 2025

L1 live sync message validation (pre Euclid V2) #245

Open

[Manager] Implement budget on future polling #246

Open

frisitano added 2 commits August 11, 2025 19:09

address comments

00d18f2

Merge branch 'main' into feat/chain-orchestrator

2beb7e0

greged93 approved these changes Aug 11, 2025

View reviewed changes

jonastheis reviewed Aug 18, 2025

View reviewed changes

jonastheis reviewed Aug 19, 2025

View reviewed changes

jonastheis reviewed Aug 20, 2025

View reviewed changes

		// Reverse the new chain headers to have them in the correct order.
		received_chain_headers.reverse();

		// Purge all pending block imports.
		self.chain_imports.clear();

		/// A `BatchCommit` event has been indexed returning the batch info and the L2 block info to
		/// revert to due to a batch revert.

	tracing::trace!(target: "scroll::engine", head = %chain_import.chain.last().unwrap().hash_slow(), "new block import request received");
	tracing::trace!(target: "scroll::engine", head = %chain_import.chain.last().unwrap().hash_slow(), "new chain import request received");

feat: chain orchestrator #185

Are you sure you want to change the base?

feat: chain orchestrator #185

Conversation

frisitano commented Jul 2, 2025 • edited by greged93 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

greged93 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

frisitano Aug 11, 2025 • 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!

frisitano Aug 20, 2025 • 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!

Uh oh!

Uh oh!

Uh oh!

greged93 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

frisitano commented Jul 2, 2025 •

edited by greged93

Loading

frisitano Aug 11, 2025 •

edited

Loading

frisitano Aug 20, 2025 •

edited

Loading