Push vector similarity functions using BlockDocValuesReader by carlosdelest · Pull Request #137002 · elastic/elasticsearch

carlosdelest · 2025-10-23T08:46:35Z

Pushes down vector similarity functions, and applies them when loading vectors.

This avoids the overhead of loading vectors into blocks, and calculate the functions afterwards in the compute engine. This directly calculates the similarity functions when loading the field, and loads the results directly into a block.

This approach consists on:

A BlockLoaderFunctionConfig marker interface, that is available on the BlockLoaderContext. This interface will be implemented by config objects, that will be used by the field types to instantiate the appropriate BlockLoader based on this config.
A BlockLoaderExpression interface. Functions that implement this interface will provide a BlockLoaderFunctionConfig.
An EsFunctionField that extends EsField. This field has a BlockLoaderFunctionConfig, which is the function configuration to extract from the field.
A PushDownVectorSimilarityFunctions local logical optimization rule, that replaces a vector similarity function applied to a field with a FieldAttribute that contains an EsFunctionField that will be used to extract the function result at field loading.

I've used a local logical optimization rule to push down. It looks cleaner and we don't have to deal with different cases when the attribute is sent to the local nodes or stays in the coordinator. Plus, it can use the mapping information to decide if a function can be pushed down or not.

Related: #103636
Previous work done on: #136739

…ectorFieldMapper and BlockDocValuesReader

… fields

…ector-similarity-blockloaders # Conflicts: # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java

…on interface to create block loader

…ector-similarity-blockloaders-function-config # Conflicts: # x-pack/plugin/esql/src/internalClusterTest/java/org/elasticsearch/xpack/esql/vector/VectorSimilarityFunctionsIT.java # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java # x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/optimizer/LogicalPlanOptimizerTests.java

…-similarity-blockloaders-function-config' into non-issue/esql-push-vector-similarity-blockloaders-function-config

nik9000

Now I'm excited. Looks great. I'd love to make the rule more generic, but that should probably wait for a follow up.

You may want to look into my comments about canonicalize - that could make this a little easier to reason about and feel fairly cheap to handle now.

I think we want a review from @alex-spies before we get this in.

I left a comment about another kind of query on the test that I think is important to address too. It's cool if we don't optimize this case now, but we shouldn't break it.

server/src/main/java/org/elasticsearch/index/mapper/MappedFieldType.java

nik9000 · 2025-10-23T14:45:16Z

...n/java/org/elasticsearch/xpack/esql/expression/function/vector/VectorSimilarityFunction.java


+    @Override
+    public MappedFieldType.BlockLoaderFunction<DenseVectorFieldMapper.VectorSimilarityFunctionConfig> getBlockLoaderFunction() {
+        Literal literal = (Literal) (left() instanceof Literal ? left() : right());


Could this return null if neither are Literal? I feel like letting the functions themselves decide when they should push is the right thing to do.

Like, we'll push stuff like ST_CENTROID and LENGTH and those don't have any literal checking. We might push DATE_PARSE which has who knows what rules.

Wait. Ignore this. Let's get it in a follow up when we do LENGTH or something. It'll be really obvious what to do then.

Can we add a comment why we can assume one side to be a literal? This reads like it has to cause a CCE in some cases; but I assume this never really happens because PushDownVectorSimilarityFunctions is required for this code to be relevant, and that checks for literals? If that's true, maybe let's even link to PushDownVectorSimilarityFunctions for ease of reading :)

nik9000 · 2025-10-23T14:46:58Z

...lasticsearch/xpack/esql/optimizer/rules/logical/local/PushDownVectorSimilarityFunctions.java

+
+    @Override
+    protected LogicalPlan rule(Eval eval) {
+        // TODO Extend to WHERE if necessary


I'd leave that for a follow up. When someone needs it.

Done in 053ea74

nik9000 · 2025-10-23T14:50:11Z

...lasticsearch/xpack/esql/optimizer/rules/logical/local/PushDownVectorSimilarityFunctions.java

+        // Only replace if exactly one side is a literal and the other a field attribute
+        if ((similarityFunction.left() instanceof Literal ^ similarityFunction.right() instanceof Literal) == false) {
+            return similarityFunction;
+        }


This can all deal with the new interface, right?

Wait. Let's just do that in a follow up. It's a good thing to do, but this feels like quite a good step.

nik9000 · 2025-10-23T14:54:03Z

...n/java/org/elasticsearch/xpack/esql/expression/function/vector/VectorSimilarityFunction.java

@@ -210,6 +206,22 @@ public void close() {
        }
    }


If you implement canonicalize you can rotate Literals to the right hand side. Then you don't need all the xor fun. That feels like it'd be easier to manage.

You can swap the order of the parameters, right? That doesn't change the meaning for any of these functions, right?

Correct, I'll do that - it's easier to reason as you say, and may benefit other cases we do optimizations for in the evaluator

nik9000 · 2025-10-23T15:01:34Z

...in/esql/src/test/java/org/elasticsearch/xpack/esql/optimizer/PhysicalPlanOptimizerTests.java

+            | eval s = v_dot_product(dense_vector, [0.1, 0.2, 0.3])
+            | sort s desc
+            | keep s
+            """;


What about a query like

from test | eval s = v_dot_product(dense_vector, [0.1, 0.2, 0.3]) * 2 + 12 | sort s desc | keep s

Does this get rewritten now? It doesn't have to in this PR, but I feel like we'd want it to eventually. And we do have to make sure not to break it in this PR either way.

What about:

from test | eval s = v_dot_product(dense_vector, [0.1, 0.2, 0.3]) + v_dot_product(dense_vector, [0.3, 0.4, 0.5]) | sort s desc | keep s

I'm not sure precisely how we'd want to push these, but again, it shouldn't break.

from test | eval s = v_dot_product(dense_vector1, [0.1, 0.2, 0.3]) + v_dot_product(dense_vector2, [0.3, 0.4, 0.5]) | sort s desc | keep s

And do we need this for the non-sorted case too? I'm not sure. I didn't read closely enough.

I think all those cases are handled, but you're right in that I need to add tests for it. Basically, each function in an expression is replaced and pushed individually. But I need to make explicit tests for it

That's tested in CSV tests and in optimizer tests in 11a6df1

carlosdelest · 2025-10-23T10:36:39Z

...n/java/org/elasticsearch/xpack/esql/expression/function/vector/VectorSimilarityFunction.java

                            // A null value on the left or right vector. Similarity is null
                            builder.appendNull();
                            continue;
-                        } else if (dimsLeft != dimsRight) {


Dimensions are checked on the similarity implementation now

carlosdelest · 2025-10-23T11:08:50Z

server/src/main/java/org/elasticsearch/index/mapper/vectors/DenseVectorFieldMapper.java

+                if (blockLoaderFunction == null) {
+                    return new BlockDocValuesReader.DenseVectorBlockLoader(name(), dims, this);
+                }
+                if (SIMILARITY_FUNCTION_NAME.equals(blockLoaderFunction.name()) == false) {


I'm not super fan of using a name to identify the function. I think we could get away with checking the type of the config 🤔

Yeah. I think you can just:

if (blockLoaderFunction == null) { return new BlockDocValuesReader.DenseVectorBlockLoader(name(), dims, this); } if (blockLoaderFunction instanceof DenseVectorSimilarityFunctionBlockLoader config) { return new BlockDocValuesReader.DenseVectorSimilarityFunctionBlockLoader( } throw new UnsupportedOperationException("Unknown block loader function: " + blockLoaderFunction);

The only thing is - we need to make sure there's a nice toString for the config.

carlosdelest · 2025-10-23T15:33:54Z

...n/java/org/elasticsearch/xpack/esql/expression/function/vector/VectorSimilarityFunction.java

@@ -210,6 +206,22 @@ public void close() {
        }
    }


Correct, I'll do that - it's easier to reason as you say, and may benefit other cases we do optimizations for in the evaluator

carlosdelest · 2025-10-23T15:34:58Z

...in/esql/src/test/java/org/elasticsearch/xpack/esql/optimizer/PhysicalPlanOptimizerTests.java

+            | eval s = v_dot_product(dense_vector, [0.1, 0.2, 0.3])
+            | sort s desc
+            | keep s
+            """;


I think all those cases are handled, but you're right in that I need to add tests for it. Basically, each function in an expression is replaced and pushed individually. But I need to make explicit tests for it

server/src/main/java/org/elasticsearch/index/mapper/MappedFieldType.java

Creates a `BlockLoader` for pushing the `LENGTH` function down into the loader for `keyword` fields. It takes advantage of the terms dictionary so we only need to calculate the code point count once per unique term loaded. This `BlockLoader` implementation isn't plugged into the infrastructure for emitting it because we're waiting on the infrastructure we've started in #137002. We'll make a follow up PR to plug this in. We're doing this mostly to demonstrate another function that we can push into field loading, in addition to the vector similarity functions we're building in #137002. We don't expect `LENGTH` to be a super hot function. If it happens to be then this'll help. Before we plug this in we'll have to figure out emitting warnings from functions that we've fused to field loading. Because `LENGTH` can emit a warning, specifically when it hits a multivalued field.

…ector-similarity-blockloaders-function-config # Conflicts: # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java

carlosdelest · 2025-10-29T11:48:43Z

OK, I think this is ready for another round!

Changes I made:

Made the pushdown rule to act on WHERE, EVAL and STATS
Take into account duplicate functions, so a single attribute is created
Serialization and equality for FunctionEsField
Fix intermediate projections (MV_EXPAND)
Added tests:
- LOOKUP JOIN and ENRICH
- Checking duplicate attributes
- Functions being part of expressions
- Add tests for FunctionEsField
- Check missing and not indexed fields cases

I believe this is ready for merging - we can take a look into issues as separate PRs.

alex-spies

Great, thanks for the iterations @carlosdelest !

I think there's still some minor work to do on the push down rule, but it's definitely very fine to do so in follow-ups! Please, proceed at your own discretion; I left some recommendations below.

alex-spies · 2025-10-29T16:56:20Z

...k/plugin/esql-core/src/main/java/org/elasticsearch/xpack/esql/core/type/FunctionEsField.java

    private final transient MappedFieldType.BlockLoaderFunctionConfig functionConfig;

-    public FunctionEsField(EsField esField, Function function, MappedFieldType.BlockLoaderFunctionConfig functionConfig) {
+    public FunctionEsField(EsField esField, DataType dataType, MappedFieldType.BlockLoaderFunctionConfig functionConfig) {


alex-spies · 2025-10-29T17:00:32Z

x-pack/plugin/esql/qa/testFixtures/src/main/resources/vector-dot-product.csv-spec

Great, thanks for the added tests!

alex-spies · 2025-10-29T17:02:38Z

...gin/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/LocalLogicalPlanOptimizer.java

+        if (EsqlCapabilities.Cap.VECTOR_SIMILARITY_FUNCTIONS_PUSHDOWN.isEnabled()) {
+            rules.add(new PushDownVectorSimilarityFunctions());
+        }


This is nice! That said, I was overly cautious about turning this off in Prod because I thought that the vec similarity functions are already live - which they aren't. So it's also fine to always enable PushDownVectorSimilarityFunctions.

alex-spies · 2025-10-29T17:03:18Z

x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/stats/DisabledSearchStats.java

@@ -19,7 +19,8 @@ public boolean exists(FieldName field) {

    @Override
    public boolean isIndexed(FieldName field) {
-        return true;
+        // Vector fields are not indexed, so vector similarity functions are be evaluated via evaluator instead of pushed down in CSV tests


alex-spies · 2025-10-29T17:09:29Z

...lasticsearch/xpack/esql/optimizer/rules/logical/local/PushDownVectorSimilarityFunctions.java

+                return esRelation.withAttributes(updatedOutput.stream().toList());
+            });
+            // Transforms Projects so the new attribute is not discarded
+            transformedPlan = transformedPlan.transformDown(EsqlProject.class, esProject -> {


This still walks the whole plan again on each Eval, Filter or Aggregate, which is a little more complex than needed (O(n^2)).

I think what you'll want to do (in a follow-up), is to just have extends Rule<LogicalPlan, LogicalPlan>, and then perform a single walk of the plan, like ResolveUnionTypes. Actually, it's probably a good idea to follow ResolveUnionTypes' general structure. The latter also checks for any already fused fields from previous passes, which we should likely also do.

That makes sense. I'll do that in a follow up though - I want this to be merged so it unblocks other related work. Thanks for the pointers!

alex-spies · 2025-10-29T17:18:37Z

...lasticsearch/xpack/esql/optimizer/rules/logical/local/PushDownVectorSimilarityFunctions.java

+            // Transforms Projects so the new attribute is not discarded
+            transformedPlan = transformedPlan.transformDown(EsqlProject.class, esProject -> {
+                List<NamedExpression> projections = new ArrayList<>(esProject.projections());
+                projections.addAll(addedAttrsList);


thought: this might run into problems in the future if data node plans ever get projects that aren't between the main EsRelation and the, say, Eval that we're currently trying to optimize. E.g. if we allow Project nodes in the right hand side of Joins.

It's fine for now, though :)

alex-spies · 2025-10-29T17:27:38Z

...lasticsearch/xpack/esql/optimizer/rules/logical/local/PushDownVectorSimilarityFunctions.java

-        var nameId = new NameId();
-        var name = rawTemporaryName(fieldAttr.name(), similarityFunction.nodeName(), nameId.toString());
-        var functionAttr = new FieldAttribute(
+        var name = rawTemporaryName(fieldAttr.name(), similarityFunction.nodeName(), String.valueOf(arrayHashCode));


You just need the hash so that the name doesn't mess up the deduplication, right?

Maybe it's easier/safer to stuff the field attr with a truncated name into the IdIgnoringWrapper, and give it a unique suffix in the actual plan. OTOH, the chance of a hash collision causing a name conflict between two different fused field attributes is likely so tiny, it almost doesn't matter.

I wonder if we could just use functionEsField.hashCode, though.

You just need the hash so that the name doesn't mess up the deduplication, right?

The problem is that the query vector needs to be taken into account - we could have two similarity functions used on the same field, but with different vectors to compare to.

I used the vector hash to take that into account and deduplicate when both the similarity function and the vector are the same.

First off: sorry, should've marked this as nit. It's a nit :) I'm just pointing it out because new folks coming across this piece of code may scratch their heads as to why a manual hash computation is added. The very slim chance of hash collisions is likely negligible.

The problem is that the query vector needs to be taken into account

I see that!

But since you use a Map<Attribute.IdIgnoringWrapper, Attribute> , the field attribute that you use as key is fully used for equality in the map, except for its NameId. Which means that, if two field attributes used as map keys have different function configurations, they should be recognized as different keys in the map, regardless of their names.

So, it should be fine to use non-unique names for the attributes that we use as keys (e.g. $$dense_vector_field$dotProduct$ - and just use unique names in the value that the key points to ($$dense_vector_field$dotProduct$1234)

Ah, I see, thanks for explaining @alex-spies !

I believe the name was being used as well on equality for IdIgnoringWrapper and that was the reason that threw me off. I'll take another look when doing the follow up 👍

alex-spies · 2025-10-29T17:30:27Z

...sql/src/test/java/org/elasticsearch/xpack/esql/optimizer/LocalLogicalPlanOptimizerTests.java

+        assertThat(Expressions.names(eval.fields()), contains("s"));
+        var alias = as(eval.fields().getFirst(), Alias.class);
+        var literal = as(alias.child(), Literal.class);
+        assertThat(literal.value(), is(nullValue()));


alex-spies · 2025-10-29T17:34:26Z

...sql/src/test/java/org/elasticsearch/xpack/esql/optimizer/LocalLogicalPlanOptimizerTests.java

+            | keep *
+            | mv_expand keyword


nit: we'll implement pushdown past project for mv expand very very soon, making this test a bit pointless. We could parse the plan and manually place a custom unary plan node after the projection, if we want to make this robust.

alex-spies · 2025-10-29T17:38:10Z

...sql/src/test/java/org/elasticsearch/xpack/esql/optimizer/LocalLogicalPlanOptimizerTests.java

+            | eval s1 = v_dot_product(dense_vector, [1.0, 2.0, 3.0]), s2 = v_dot_product(dense_vector, [1.0, 2.0, 3.0]) * 2 / 3
+            | eval s3 = v_dot_product(dense_vector, [1.0, 2.0, 3.0]) + 5, r1 = v_dot_product(dense_vector, [4.0, 5.0, 6.0])
+            | eval r2 = v_dot_product(dense_vector, [4.0, 5.0, 6.0]) + v_cosine(dense_vector, [4.0, 5.0, 6.0])


I think you'll see more interesting results when we use the same dot product in different commands. E.g. one EVAL, one WHERE, on STATS.

We combine subsequent EVALs, so you don't see the effect of the same similarity function occuring in different commands.

True! As I need to rework the pushddown rule in a follow up, and it will traverse the plan in one go, I'll update the test accordingly there 👍

…ector-similarity-blockloaders-function-config # Conflicts: # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java

We have a bunch of these as inner classes. Some of them are inner classes of the field types they support - which is fine and good. But a bunch of the shared ones were inner classes of `BlockDocValuesReader` which made the class like a billion lines long. And it made it harder to find the source code of the shared ones because they weren't in alphabetical order. This moves these block loaders to top level classes. And lets our IDE put them in alphabetical order for us. Which is nice because we'll be adding a bunch more of them as we move further on elastic#137002.

Creates a `BlockLoader` for pushing the `LENGTH` function down into the loader for `keyword` fields. It takes advantage of the terms dictionary so we only need to calculate the code point count once per unique term loaded. This `BlockLoader` implementation isn't plugged into the infrastructure for emitting it because we're waiting on the infrastructure we've started in elastic#137002. We'll make a follow up PR to plug this in. We're doing this mostly to demonstrate another function that we can push into field loading, in addition to the vector similarity functions we're building in elastic#137002. We don't expect `LENGTH` to be a super hot function. If it happens to be then this'll help. Before we plug this in we'll have to figure out emitting warnings from functions that we've fused to field loading. Because `LENGTH` can emit a warning, specifically when it hits a multivalued field.

…137002)

BASE=82df0825778dc24773236299d5ecff6ae48d6786 HEAD=23450dd9771a51939201e641b79ad16fee302ff7 Branch=main

elasticsearchmachine added 23 commits October 14, 2025 20:25

Add value transformations to BlockLoaderContext, apply them in DenseV…

5fd5f9a

…ectorFieldMapper and BlockDocValuesReader

Add value transformation to shard context

1ace6cd

Add transformations to vector similarity functions

0e12f0b

Add push down rule

63b0974

Introduce new interface BlockValueLoader for loading and transforming…

c5a8f45

… fields

Additional method for a new class in Dense Vector

f5ec0b1

Refactor before bytes

94610c2

Added byte support

c8b67a0

Refactoring

59b9c37

Refactoring and comments

566926d

Leave the original field to extract if needed

e5095b0

Use a better mechanism for temp field names

a2a855d

Add comments

2e409c0

WIP for logical plan

f363dff

Merge remote-tracking branch 'origin/main' into non-issue/esql-push-v…

bd687ec

…ector-similarity-blockloaders # Conflicts: # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java

Use a Function in FieldFunctionAttribute, and use a BlockLoaderFuncti…

1dacd0e

…on interface to create block loader

Removed FieldExtractPreference.FUNCTION

c8ab6f7

Use a BlockLoaderFunction that consists of a name and a config

bc34ed4

Some renaming

f7410fb

Spotless

2b02844

Add testing

18187be

Fix tests

234dfd7

elasticsearchmachine added the v9.3.0 label Oct 23, 2025

elasticsearchmachine added 4 commits October 23, 2025 08:53

[CI] Auto commit changes from spotless

c11fe27

Javadoc, spotless

5bd4029

Merge remote-tracking branch 'carlosdelest/non-issue/esql-push-vector…

8783191

…-similarity-blockloaders-function-config' into non-issue/esql-push-vector-similarity-blockloaders-function-config

Remove unchecked

21ac1b6

nik9000 approved these changes Oct 23, 2025

View reviewed changes

carlosdelest commented Oct 23, 2025

View reviewed changes

elasticsearchmachine added 2 commits October 28, 2025 16:44

Fix javadoc

0f12e78

Deduplicate attributes

11a6df1

elasticsearchmachine added 7 commits October 29, 2025 10:49

Add enrich and lookup CSV tests

67f7cce

Spotless

593fe6a

Fix CSV test files

6f33df8

Merge remote-tracking branch 'origin/main' into non-issue/esql-push-v…

33e0de2

…ector-similarity-blockloaders-function-config # Conflicts: # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java

Fix capabilities in CSV test files

02d53f8

Fix CSV tests

dd5f09f

Add test for non pushed down vector similarity functions

ba8d661

carlosdelest requested a review from alex-spies October 29, 2025 11:39

[CI] Auto commit changes from spotless

a3776cc

alex-spies approved these changes Oct 29, 2025

View reviewed changes

Merge remote-tracking branch 'origin/main' into non-issue/esql-push-v…

23450dd

…ector-similarity-blockloaders-function-config # Conflicts: # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java

carlosdelest enabled auto-merge (squash) October 30, 2025 08:32

carlosdelest merged commit d220b33 into elastic:main Oct 30, 2025
33 of 34 checks passed

This was referenced Oct 30, 2025

ES|QL - dense_vector exact (brute force) search support #130828

Closed

ES|QL - Expression field loading follow ups #137392

Closed

carlosdelest mentioned this pull request Nov 3, 2025

ES|QL - Improve performance of V_MAGNITUDE function #137535

Open

chrisparrinello pushed a commit to chrisparrinello/elasticsearch that referenced this pull request Nov 3, 2025

Push vector similarity functions using BlockDocValuesReader (elastic#…

22a85bd

…137002)

carlosdelest mentioned this pull request Nov 4, 2025

ES|QL - vector similarity pushdown follow up #137564

Merged

pmpailis mentioned this pull request Nov 5, 2025

Updating one-dim VectorSimilarityFunction tests to account for null input #137620

Merged

phananh1010 added a commit to phananh1010/elasticsearch that referenced this pull request Nov 6, 2025

Mirror upstream elastic#137002 as single snapshot commit for AI review

c7e3fcd

BASE=82df0825778dc24773236299d5ecff6ae48d6786 HEAD=23450dd9771a51939201e641b79ad16fee302ff7 Branch=main

carlosdelest mentioned this pull request Nov 7, 2025

ESQL: Make field fusion generic #137382

Merged

This was referenced Nov 14, 2025

ESQL: improve performance - Merge functions into loaders (sometimes) #103636

Closed

ES|QL - Move dense vector similarity functions into release builds #138274

Closed

carlosdelest mentioned this pull request Dec 11, 2025

ES|QL - Add vector similarity functions to tech preview, allow pushdown of blockloader functions #139365

Merged

Conversation

carlosdelest commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

nik9000 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

carlosdelest commented Oct 29, 2025

alex-spies left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alex-spies Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

Labels

4 participants

carlosdelest commented Oct 23, 2025 •

edited

Loading

alex-spies Oct 30, 2025 •

edited

Loading