[resource] introduce reference based attributes #733

florianl · 2025-10-30T09:53:20Z

Reduce duplicate entries by using a reference based approach in combination with a lookup table.

It should help drive the discussion around the use or Resources.

FYI: @open-telemetry/profiling-approvers

We will include a int32 string_value_ref field within the AnyValue message. This allows data points to reference strings via an integer index rather than carrying the full string value.

Collector Efficiency: This is the most pragmatic path to simplify the OpenTelemetry Collector's internal data model (pdata) and streamline code generation.
Consolidation: While creating a separate "Ref" version of AnyValue was considered, it was determined that the confusion caused by a new type would be equal to or greater than simply adding a field to the existing message.
Minimized Impact: In signals where no dictionary is provided (like standard Traces or Metrics), this field has no context and should be ignored, minimizing the risk of accidental misuse.

Reduce duplicate entries by using a reference based approach in combination with a lookup table. Signed-off-by: Florian Lehner <[email protected]>

tigrannajaryan · 2025-10-30T14:22:14Z

I have 2 questions:

Do we want ref attributes only for string values or other value types as well? I understand they are pointless for bool/int attributes, but can be useful for more complex attributes (outside profiling).
Have we considered modifying AnyValue definition to allow for string refs instead of modifying the Resource. This way we can have ref-base attributes for all attributes not just for the Resource, e.g.:

message AnyValue {
  oneof value {
    ...
    uint32 string_ref = 8;
  }
}

tigrannajaryan · 2025-10-30T14:30:37Z

I would like to see some benchmarks showing the impact of the change on profiling signals. I think we want to see the following with and without ref-based attributes on a few production-like payloads:

Wire size uncompressed.
Wire size compressed with zstd and/or gzip.
In-memory size in one popular language (preferably Go for Collector impact).
Serialization/deserialization speed (CPU time), including dictionary construction if string interning is not already somehow happening at the source.

This is a pretty significant change so I want benchmarks to support the change.

felixge · 2025-10-30T14:42:37Z

opentelemetry/proto/resource/v1/resource.proto

+  int32 key_index = 1;
+
+  // Reference to the value of the pair in ProfilesDictionary(?).string_table.
+  int32 value_index = 2;


Do we want the value type to be restricted to strings? If not, we should probably do it like we do for the attributes in profiling?

Of course this means no dictionary for the values, but they're supposed to be low cardinality.

Suggested change

int32 value_index = 2;

opentelemetry.proto.common.v1.AnyValue value = 2;

Edit: I see @tigrannajaryan asked similar questions above.

Just wanted to get the discussion started.

The recommendation in #733 (comment) sounds promissing:

message AnyValue { oneof value { ... uint32 string_ref = 8; } }

I think, we definitely should also reference string values.

Yeah, giving AnyValue the ability to reference into the string table would be useful. But it seems like that would be an additional step we could take that doesn't need to be in the scope of this PR? Especially if we apply the change I suggested.

Updating AnyValue with the ability to use a reference as a next step sound good to me. Applying the changes to message Resource in a first step limits also the number of follow up changes in other components, like OTel collector or SDKs.

Applying the changes to message Resource in a first step limits also the number of follow up changes in other components, like OTel collector or SDKs.

I disagree that this is a good approach. It creates an intermediary state that is going to be short-lived, which we have to get rid of once AnyValue gains ref capability. So the anticipated changes to the protocol look like this:

Add ref attributes to Resource.

Add ref to AnyValue.

Deprecate ref attributes in Resource, but keep supporting both refs.

Wait for a few years for the next major version of OTLP where we can make breaking changes.

Delete ref attributes from Resource.

Consider instead this:

Add refs to AnyValue. Done.

@tigrannajaryan applied the requested changes with c8b22c6.

felixge · 2025-10-30T14:47:32Z

This is a pretty significant change so I want benchmarks to support the change.

Agreed. @Gandem and I started working on this yesterday. Our rough plan is the following:

Capture OTLP data from a suitable workload. We're thinking a python app that forks one process per CPU core on a 16+ core machine. We can add more workload recordings later.
Implement a otlp-bench tool in sig-profiling: The tool takes OTLP profiling payloads and converts them into the new proposed dictionary encoding to compare the resulting size. This tool should also be suitable for other experiments in the future.

We hope to have it done by the Nov 13 profiling SIG meeting.

tigrannajaryan · 2025-10-30T17:43:11Z

Implement a otlp-bench tool in sig-profiling: The tool takes OTLP profiling payloads and converts them into the new proposed dictionary encoding to compare the resulting size. This tool should also be suitable for other experiments in the future.

@felixge My old bench from early OTLP designs is here: https://github.com/tigrannajaryan/exp-otelproto

Feel free to borrow anything if there is any useful/relevant stuff there. Might be outdated/bitrotten since it's been a while.

felixge · 2025-10-31T06:20:31Z

opentelemetry/proto/resource/v1/resource.proto

+  int32 key_index = 1;
+
+  // Reference to the value of the pair in ProfilesDictionary(?).string_table.
+  int32 value_index = 2;


Yeah, giving AnyValue the ability to reference into the string table would be useful. But it seems like that would be an additional step we could take that doesn't need to be in the scope of this PR? Especially if we apply the change I suggested.

opentelemetry/proto/resource/v1/resource.proto

…ct_attributes-field-name add missing dict_attributes field name

opentelemetry/proto/resource/v1/resource.proto

tigrannajaryan · 2025-10-31T15:30:00Z

opentelemetry/proto/resource/v1/resource.proto

+  // Note: This is currently used exclusively in the Profiling signal.
+  //
+  // Status: [Development]
+  repeated StringKeyValue dict_attributes = 4;


What happens if the same key is present here and in attributes? Do we need precedence rules? Is it invalid state?

My suggestion is that if there are elements in dict_attributes, then attributes must not hold any element.

Let's add that as an invariant in the comments then

tigrannajaryan

Blocking until we have clarity on the way forward.

Signed-off-by: Florian Lehner <[email protected]>

tigrannajaryan · 2025-11-03T17:32:30Z

@open-telemetry/profiling-maintainers I would like to see a proper OTEP for this change. It should include the following:

Benchmarks to demonstrate that it serves the declared purpose (performance gains, on what aspects and by how much). This is a pre-requisite, we should not move forward without this proof.
How interoperabilty will be ensured for stable signals. We can't introduce this change first and think about interoperability later as a separate change, because we are touching common messages that are used by stable signals. We need to know now how exactly this will work in the future otherwise we risk introducing something that will have to be changed again. A possible approach like I mentioned earlier is introducing "capability" negotiation into OTLP (similar to OpAMP capabilities). I am happy to work together with you on this.

felixge · 2025-11-04T06:07:52Z

@open-telemetry/profiling-maintainers I would like to see a proper OTEP for this change. It should include the following:

Benchmarks to demonstrate that it serves the declared purpose (performance gains, on what aspects and by how much). This is a pre-requisite, we should not move forward without this proof.

Ack. Working on it.

How interoperabilty will be ensured for stable signals. We can't introduce this change first and think about interoperability later as a separate change, because we are touching common messages that are used by stable signals. We need to know now how exactly this will work in the future otherwise we risk introducing something that will have to be changed again. A possible approach like I mentioned earlier is introducing "capability" negotiation into OTLP (similar to OpAMP capabilities). I am happy to work together with you on this.

Can you sync with @jsuereth on this? We discussed this with him in the last SIG meeting and he didn't see large obstacles, e.g. the need for capability negotiation.

The rough plan is that the new dict_attributes will be opaque to the collector. The idea is to adjust the codegen for pdata so that Resource.Attributes() returns the regular attributes as well as any attributes from dict_attributes. What do you think?

tigrannajaryan · 2025-11-04T15:25:55Z

The rough plan is that the new dict_attributes will be opaque to the collector. The idea is to adjust the codegen for pdata so that Resource.Attributes() returns the regular attributes as well as any attributes from dict_attributes. What do you think?

Let's set aside what happens inside the Collector for a moment.

I am looking at a scenario where a pair of OTLP sender and receiver of different versions try to communicate (can be SDK, Collector, a backend, etc).

What happens if the OTLP sender uses the new version of protocol and encodes some attributes via dictionary, however the receiver is an old version and does not know anything about dictionaries? The receiver will see AnyValue with a oneof set to an unknown proto field number. (I am assuming we go with the current state of this PR that add string_ref to AnyValue). It will be most likely treated as an empty AnyValue by most receivers and will result in data loss or at best detected as unknown/invalid AnyValue (and still result in data loss or impossibility to communicate).

I do not think this is acceptable.

Can you sync with @jsuereth on this? We discussed this with him in the last SIG meeting and he didn't see large obstacles, e.g. the need for capability negotiation.

@jsuereth let's discuss in spec meeting today if you are around. @felixge and other @open-telemetry/profiling-maintainers it would be good if you can join too.

bogdandrutu · 2025-11-04T16:29:01Z

opentelemetry/proto/resource/v1/resource.proto

+  // Set of attributes that describe the resource.
+  // Key and Value combination MUST be unique.
+  // attributes MUST NOT be used if dict_attributes is used.
+  //
+  // Note: This is currently used exclusively in the Profiling signal.
+  //
+  // Status: [Development]
+  repeated RefKeyValue dict_attributes = 4;


I would put the dictionary in the "ResourceLogs/ResourceSpans/ResourceMetrics" and be shared between all attributes coming from a resource?

happy to hear others what they think

Thanks for the suggestion. Quick context: the technical committee (cc @jsuereth) recommended we follow the OpenTelemetry resource model in the opentelemetry-ebpf-profiler and align with the SDKs’ resource definition.

Today the profiler emits one resource per container (container.id) plus one for everything else. Aligning with the SDKs would mean one resource per process id.

In forking runtimes like Python, a single container often runs many processes. Those processes share almost identical resource attributes (container.id, container.name, etc.). Replicating them across 10 to 20 processes increases the profiling payload, especially the collector’s in-memory footprint.

The benchmarks I’m running with @felixge aim to quantify that overhead and the savings from a dictionary defined at the top level.

If we scope the dictionary to each Resource or inside ResourceLogs/ResourceSpans/ResourceMetrics, it can’t de-duplicate across separate Resource instances once we move to per-process resources. That defeats the goal and wouldn’t prevent the payload growth we’re trying to avoid.

If we scope the dictionary to each Resource or inside ResourceLogs/ResourceSpans/ResourceMetrics, it can’t de-duplicate across separate Resource instances once we move to per-process resources. That defeats the goal and wouldn’t prevent the payload growth we’re trying to avoid.

Do you think you can run the benchmarks with both approaches (what you suggest and what Bogdan suggests) so that we can see the difference?

bogdandrutu · 2025-11-04T16:35:58Z

opentelemetry/proto/common/v1/common.proto

+    // Note: This is currently used exclusively in the Profiling signal.
+    //
+    // Status: [Development]
+    int32 string_ref = 8;


Should we use fixed32 instead? It is faster but a bit larger on the wire.

I think I would keep varint because then we could use lower values for more commonly referenced values and save wire size.

felixge · 2025-11-05T08:10:00Z

What happens if the OTLP sender uses the new version of protocol and encodes some attributes via dictionary, however the receiver is an old version and does not know anything about dictionaries? The receiver will see AnyValue with a oneof set to an unknown proto field number. (I am assuming we go with the current state of this PR that add string_ref to AnyValue). It will be most likely treated as an empty AnyValue by most receivers and will result in data loss or at best detected as unknown/invalid AnyValue (and still result in data loss or impossibility to communicate).

I do not think this is acceptable.

The string_ref field is documented as: This is currently used exclusively in the Profiling signal.. If the receiver doesn't know about the profiling signal ... there is nothing we can do about that.

As far as expanding the usage of this field to other signals, that's indeed a problem. Is this the first time a new field is being added to OpenTelemetry? Is there no prior art?

@jsuereth let's discuss in spec meeting today if you are around. @felixge and other @open-telemetry/profiling-maintainers it would be good if you can join too.

Sorry I wasn't able to join, but the notes indicate that @florianl and you will work on an OTEP for that? That sounds good, thanks 🙇.

I hope to have the new benchmarks soon.

opentelemetry/proto/common/v1/common.proto

opentelemetry/proto/resource/v1/resource.proto

Signed-off-by: Florian Lehner <[email protected]>

opentelemetry/proto/resource/v1/resource.proto

…i2bIKB4hrYZQ6rGE Signed-off-by: Florian Lehner <[email protected]>

florianl · 2025-11-14T11:50:14Z

I have updated this PR to reflect the changes suggested in the OTEP.

felixge · 2025-11-27T15:55:05Z

@Gandem and I have finished the benchmark we promised. You can view the full results here:

The results conclude that this PR is effective and reduces the uncompressed payload size by 40% and gzip-6 compressed payload size by 4% for a k8s workload with frequent process forking when comparing the split-by-process vs resource-attr-dict approach.

file	encoding	payloads	uncompressed_bytes	gzip_6_bytes
testdata/k8s_big_fork.otlp	baseline	20	28979846	9321556
testdata/k8s_big_fork.otlp	split-by-process	20	62905497	9591208
testdata/k8s_big_fork.otlp	resource-attr-dict	20	37766479	9220612

A visualization of the uncompressed_bytes column is shown below.

To see the full results, check out this this README.

bogdandrutu · 2025-11-29T00:49:15Z

@felixge these days zstd is more of a standard than the gzip, can you try that as well?

jack-berg · 2025-12-02T16:27:03Z

However, we want to leave the door open for other (including currently stable) signals to support attribute dictionaries in the future. We should prefer to design attribute dictionaries for profiling in a way that allows reusing the same mechanism consistently for other signals in the future.

This is nice because it avoids us having to solve the thorny problems of evolving the stable signals to use dictionaries, but its means that OTLP receivers have to operate in a split brain world, with some signals encoding using dictionaries and others not. This has consequences for things like pdata, which now need to accommodate both worlds.

I wonder if the move to reference based attributes in protos, which are occurring here and with entities, are a big enough shift that we should consider moving them to an OTLP v2.

Signed-off-by: Florian Lehner <[email protected]>

florianl · 2025-12-04T07:43:09Z

As the tendency is towards AnyRefValue rather than just adding a reference field in the oneof field in AnyValue the PR got updated.

jsuereth · 2025-12-05T17:57:43Z

opentelemetry/proto/resource/v1/resource.proto

+  // Note: This is currently used exclusively in the Profiling signal.
+  //
+  // Status: [Development]
+  repeated opentelemetry.proto.common.v1.KeyRefValue dict_attributes = 4;


What would the performance look like if you used KeyValueAndUnit refs here (where unit is always empty) to see if this saved more data?

I don't have data to back this, but I assume no difference to the benchmark results we see with #733 (comment).
As most of the time, the additional Unit field is not set it will not cause an overhead. And for the time it is actually set, it will be neglectable.

The Profiling SIG introduced KeyValueAndUnit as we see the need to assign units to values. As an additional field, like Unit, is just an additional and not a breaking change, shouldn't the discussion around Unit separated from the reference based attributes?

In support of open-telemetry/opentelemetry-proto#733 --------- Co-authored-by: Nayef Ghattas <[email protected]>

opentelemetry/proto/common/v1/common.proto

Signed-off-by: Florian Lehner <[email protected]>

I am removing my block since I no longer think I have a better proposal.

christos68k · 2026-01-12T10:55:36Z

opentelemetry/proto/common/v1/common.proto

+  // in which case this AnyRefValue is considered to be "empty".
+  oneof value {
+    // Reference to the string value in ProfilesDictionary.string_table.
+    int32 string_value_ref = 1;


@bogdandrutu can you please clarify your views on:

references folded into AnyValue or introduced with a new message AnyRefValue as done here? IIRC you expressed a preference for the former in the last Zoom chat we had. @jsuereth and @tigrannajaryan expressed preference for the latter.

references existing in the proto vs pdata? If I'm not mistaken, you've also expressed a preference for the former.

@tigrannajaryan @jsuereth my understanding of the decision is that we will add string_value_ref in the current AnyValue and will comment that is not available for other signals.

add string_value_ref in the current AnyValue

I will update this PR, once @tigrannajaryan @jsuereth also agree on that.

Signed-off-by: Florian Lehner <[email protected]>

bogdandrutu · 2026-01-20T16:53:45Z

opentelemetry/proto/common/v1/common.proto

+    // Note: This is currently used exclusively in the Profiling signal.
+    //
+    // Status: [Development]
+    int32 string_value_ref = 8;


Just for me to understand, in comment you suggest uint and here you are using the signed version. What is the expectation?

Sorry for the typo - should be int32. Updated the comment accordingly.

jsuereth · 2026-01-22T16:23:10Z

opentelemetry/proto/common/v1/common.proto

+    // Note: This is currently used exclusively in the Profiling signal.
+    //
+    // Status: [Development]
+    int32 string_value_ref = 8;


As discussed in the SIG call - I'm fine with this as a first step.

I do think you need an update to KeyValue as well where the key is a key_ref, otherwise we aren't solving the bloat problem that motivated this.

Additionaly, just re-expressing my preference that we have a ProfileResource that mirrors (but is different than) Resource and uses a KeyValueRef. We then have the Collector pdata abstract between KeyValueRef/KeyValue and ProfileResource/Resource with the same datastructure to represent both, and serialize apporpriately on the other end.

However, if that's not an option for the collector (due to performance or other concerns) we should move forward with this. cc @bogdandrutu / @tigrannajaryan

The problem to have "two things" that act the same in golang is that you need to use any (interfaces). Interfaces in golang most of the time require an extra allocation which is unnecessary.

So the option would be to actually behind the scene in the collector generate only one message Resource (and do exactly what I suggest here but hide in the back that there are 2 messages).

My problem with 2 messages is that profiles wants to add Unit for attributes for example and by being different they feel that is ok and added it without making a global decision.

@jsuereth I have added the changes for KeyValue with 2542b13 - hope this works for you?

@bogdandrutu do you have concerns about this?

My problem with 2 messages is that profiles wants to add Unit for attributes for example and by being different they feel that is ok and added it without making a global decision.

I think there's some allowable inconsistency between signals. The decision to have units - I think would be inline w/ a multivariate-metric signal, if we were to add one. Additionally, the decision to add unit was part of the -proto repo, approved by proto maintainers and merged after accepting it as a global decision. Can you clarify how it wasn't? We decided to accept this inconsistency, given trade offs.

If we don't like the inconsitency, then let's propose something that works (or at least, also propose how to deal with all the downsides) of an alternative. Right now, when the two options are "be consistent, but break the ecosystem" or "be inconsistent, but profiling is successful and existing integrations do not break" it's hard to understand the consistency argument.

opentelemetry/proto/common/v1/common.proto

Signed-off-by: Florian Lehner <[email protected]>

jsuereth · 2026-01-23T18:30:16Z

opentelemetry/proto/common/v1/common.proto

  AnyValue value = 2;
+
+  // Reference to the string key in ProfilesDictionary.string_table.
+  // key MUST NOT be set if key_ref is used.


NIT: In proto3, wihtout the use of optional, there's not really a way to check "existence" or non-existence. I think we could just say key_ref is not set or the proto3 default value of empty.

I assume 0 value is invalid for a reference, which makes it pretty easy to check for "existence" without relying on Protobuf's native existence APIs. 0 is also not going to be present on the wire, so it is safe to set it to 0 on the sender's side to indicate that the key is not refcounted.

Right, by convention all dictionary tables use index 0 to indicate 'null' / 'not set'.

Would prefer this sentence rephrased to something like this:

key MUST NOT be set if key_ref is set to a value other than 0.

[resource] introduce reference based attributes

2d6e50f

Reduce duplicate entries by using a reference based approach in combination with a lookup table. Signed-off-by: Florian Lehner <[email protected]>

felixge reviewed Oct 30, 2025

View reviewed changes

add missing dict_attributes field name

febdb7c

felixge reviewed Oct 31, 2025

View reviewed changes

Merge pull request #3 from felixge/felix.geisendoerfer/add-missing-di…

b0a24a7

…ct_attributes-field-name add missing dict_attributes field name

florianl commented Oct 31, 2025

View reviewed changes

opentelemetry/proto/resource/v1/resource.proto Outdated Show resolved Hide resolved

Apply suggestion from @florianl

6346ef0

florianl commented Oct 31, 2025

View reviewed changes

opentelemetry/proto/resource/v1/resource.proto Outdated Show resolved Hide resolved

Apply suggestion from @florianl

9150d40

florianl marked this pull request as ready for review October 31, 2025 06:58

tigrannajaryan reviewed Oct 31, 2025

View reviewed changes

tigrannajaryan previously requested changes Oct 31, 2025

View reviewed changes

florianl added 3 commits November 3, 2025 16:30

use reference in AnyValue

c8b22c6

Signed-off-by: Florian Lehner <[email protected]>

fix import path

7e6c78f

Signed-off-by: Florian Lehner <[email protected]>

fixup: add new line

bcbee5a

Signed-off-by: Florian Lehner <[email protected]>

bogdandrutu reviewed Nov 4, 2025

View reviewed changes

aalexand reviewed Nov 5, 2025

View reviewed changes

opentelemetry/proto/common/v1/common.proto Outdated Show resolved Hide resolved

aalexand reviewed Nov 5, 2025

View reviewed changes

opentelemetry/proto/resource/v1/resource.proto Outdated Show resolved Hide resolved

florianl and others added 2 commits November 5, 2025 17:13

rename fields

52a8e7b

Signed-off-by: Florian Lehner <[email protected]>

Merge branch 'main' into resource-reference

43329b0

florianl commented Nov 5, 2025

View reviewed changes

opentelemetry/proto/resource/v1/resource.proto Show resolved Hide resolved

apply https://docs.google.com/document/d/1v-XlgxnyyIsT-azCsfHJdRzVx-E…

0ae008f

…i2bIKB4hrYZQ6rGE Signed-off-by: Florian Lehner <[email protected]>

felixge mentioned this pull request Nov 27, 2025

Resource Attribute Dictionary Benchmark open-telemetry/sig-profiling#21

Merged

felixge approved these changes Nov 28, 2025

View reviewed changes

florianl added 2 commits December 4, 2025 08:28

drop reference in AnyValue.oneof approach

ffe526d

Signed-off-by: Florian Lehner <[email protected]>

return to AnyRefValue approach

55677c2

Signed-off-by: Florian Lehner <[email protected]>

jsuereth reviewed Dec 5, 2025

View reviewed changes

christos68k pushed a commit to open-telemetry/sig-profiling that referenced this pull request Dec 9, 2025

Resource Attribute Dictionary Benchmark (#21)

ec8a031

In support of open-telemetry/opentelemetry-proto#733 --------- Co-authored-by: Nayef Ghattas <[email protected]>

felixge reviewed Dec 10, 2025

View reviewed changes

opentelemetry/proto/common/v1/common.proto Show resolved Hide resolved

fix field number

82ae893

Signed-off-by: Florian Lehner <[email protected]>

christos68k reviewed Jan 12, 2026

View reviewed changes

florianl added 2 commits January 20, 2026 09:40

revert to AnyValue approach

41bb8b7

Signed-off-by: Florian Lehner <[email protected]>

drop remaining comment

617d9f0

Signed-off-by: Florian Lehner <[email protected]>

bogdandrutu reviewed Jan 20, 2026

View reviewed changes

florianl requested review from bogdandrutu, jsuereth and tigrannajaryan January 22, 2026 09:02

Gandem approved these changes Jan 22, 2026

View reviewed changes

christos68k approved these changes Jan 22, 2026

View reviewed changes

jhalliday approved these changes Jan 22, 2026

View reviewed changes

jsuereth approved these changes Jan 22, 2026

View reviewed changes

jsuereth reviewed Jan 22, 2026

View reviewed changes

opentelemetry/proto/common/v1/common.proto Show resolved Hide resolved

florianl added 2 commits January 23, 2026 15:14

extend comment

b67fa91

Signed-off-by: Florian Lehner <[email protected]>

add reference to KeyValue

2542b13

Signed-off-by: Florian Lehner <[email protected]>

jsuereth reviewed Jan 23, 2026

View reviewed changes

	int32 value_index = 2;
	opentelemetry.proto.common.v1.AnyValue value = 2;

[resource] introduce reference based attributes #733

Are you sure you want to change the base?

[resource] introduce reference based attributes #733

Conversation

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

Uh oh!

Uh oh!

tigrannajaryan commented Oct 30, 2025

Uh oh!

tigrannajaryan commented Oct 30, 2025

Uh oh!

felixge 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

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!

florianl Nov 3, 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!

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

Uh oh!

Uh oh!

tigrannajaryan commented Oct 30, 2025

Uh oh!

Choose a reason for hiding this comment

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!

tigrannajaryan left a comment

Choose a reason for hiding this comment

Uh oh!

tigrannajaryan commented Nov 3, 2025

Uh oh!

felixge commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tigrannajaryan commented Nov 4, 2025

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!

felixge commented Nov 5, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

florianl commented Nov 14, 2025

Uh oh!

felixge commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bogdandrutu commented Nov 29, 2025

Uh oh!

jack-berg commented Dec 2, 2025

Uh oh!

florianl commented Dec 4, 2025

Uh oh!

Choose a reason for hiding this comment

florianl commented Oct 30, 2025 •

edited

Loading

felixge Oct 30, 2025 •

edited

Loading

florianl Nov 3, 2025 •

edited

Loading

felixge commented Oct 30, 2025 •

edited

Loading

felixge commented Nov 4, 2025 •

edited

Loading

felixge commented Nov 27, 2025 •

edited

Loading

florianl Dec 8, 2025 •

edited

Loading

florianl Jan 20, 2026 •

edited

Loading