Update guidance on required field serialization #8486

JoelSpeed · 2025-06-12T09:51:52Z

@liggitt and I were discussing serialization of required fields in a thread and realised that there are valid cases where a required field should be a pointer and should be omitempty.

Take the example:

// +required
// +k8s:minimum=0
Foo *int32 `json:"foo,omitempty"`

Here, the value 0 is a valid user choice.

For a structured Go client, if the field were not a pointer, and not omitempty per the existing guidance, then the structured client is not actually required to set a value for the field, as the json marshalling process will marshal foo: 0 and set a choice for them.

This defeats the purpose of the field being required for structured clients, and creates a discrepancy in behaviour between structured and unstructured clients.

Would appreciate thoughts of other API reviewers on this
CC @thockin @deads2k

JoelSpeed · 2025-06-12T10:28:24Z

Thinking through different types we might see, and the implications of this suggestion

Nullable

Anything that needs to be a pointer to allow the zero value to be set, that also has +nullable, does not need to be omitempty. +nullable and omitempty are incompatible.

String

Any required string should have a minimum length. If that minimum length is 0, or unset, then the string should be a pointer+omitempty to allow the empty string to be an explicit choice.

Except when the required string is not actually a string.

Enums would not need to be pointer+omitempty unless the empty string is a valid value in the enum
Time: Parsing the empty string returns an error when unmarshalling

Integer/Float

As per example in the decsription, if the 0 is in the valid range of values (based on minimum/maximum markers) then pointer and omitempty should be used to allow 0 to be a valid choice.

Bool

Any required bool should be a pointer+omitempty unless validation only allows the value true. (I have no idea if we have that in any APIs?)

Lists

A required list should have a minimum length validation (+k8s:minItems). If that minimum length is 0, or unset, then the list should be a pointer and omitempty (Foo *[]string json:"foo,omitempty"`).

If the list wasn't a pointer, but had omitempty, the structured client would not be able to explicitly set an empty list.

Maps

The same as lists? Not sure what the appropriate marker is for the minimum size of a map (it's +kubebuilder:validation:MinProperties in CRDs)

Objects

For the zero value to be valid, an object should have no required fields, and have no validation that requires a minimum number of fields be set (e.g. +kubeubilder:validationMinProperties, not sure on equivalent +k8s marker). In these cases then the object should be pointer+omitempty to be able to explicitly set the zero value {}.

If the object does have a required field, but that required field would marshal the zero value and that would be accepted by validation, then the zero value of the struct would also be considered valid. I think this would happen generally on a poorly validated set of fields. E.g. a string that doesn't have an explicit minimum length, but has not been added based on the rules outlined here.

The object "bar": {"foo": ""} might be the minimally serialized object, and this would pass the bar and foo validations for being required. But "bar": {} would not pass the validation of foo required, and as such, the object does not need to be a pointer in this case.

sbueringer · 2025-06-12T12:55:18Z

contributors/devel/sig-architecture/api-conventions.md

@@ -843,10 +843,10 @@ having the `+optional` comment tag is highly recommended.
 Required fields have the opposite properties, namely:

 - They do not have an `+optional` comment tag.
- They do not have an `omitempty` struct tag.
- They are not a pointer type in the Go definition (e.g. `AnotherFlag SomeFlag`).
+- They mark themselves as required explicitly with a `+required` comment tag, or implicitly by not setting an `omitempty` struct tag.


I don't have enough context, but could we simplify this guidance to required fields are only marked via the +required marker (given that's how it should be)

Or at least recommend it

+1 - explicit FTW. If declarative validation flies, I want explicit.

I also believe in being explicit, but I know some tooling is implicitly assuming this, and we have a long history of that implicitness.

If we say they should be explicitly marked, should we also add an N.B. that explains that historically this has been implicitly detected?

If we say they should be explicitly marked, should we also add an N.B. that explains that historically this has been implicitly detected?

I was thinking something like this, yes. Recommend to be explicit and then mention in some way how some tools behave (probably these tools (thinking about controller-gen as an example) also won't change to avoid breaking changes)

JoelSpeed · 2025-06-12T17:17:13Z

/hold

I've been through this with @liggitt and we need to make some more updates to the guidance. Will look at creating a decision tree to help folks understand whether or not they should be setting fields as pointers/omitempty etc

liggitt · 2025-06-12T17:19:50Z

(notes from our discussion in https://docs.google.com/document/d/1k3XxUTEjcQifSXjoy5CcQY9QttdhQ-EG-R3vrKq6SUc/edit?pli=1&resourcekey=0-5xMYchKvoisABPw9tsR3nA&tab=t.0#bookmark=id.ks1ziis4vgzz - shared with https://groups.google.com/a/kubernetes.io/g/dev, can join that to get read access)

thockin · 2025-06-12T23:29:24Z

contributors/devel/sig-architecture/api-conventions.md

 - The API server should not allow POSTing or PUTing a resource with this field
 unset.
+- They _typically_ do not use pointer types in the Go definition (e.g. `AnotherFlag SomeFlag`), though required fields where the zero value is a valid value may use pointer types, likely paired with an `omitempty` struct tag to avoid spurious null serializations.


"may" or "must" ?

I think this is must and likely paired, should remove likely

fabriziopandini · 2025-06-17T15:46:48Z

@JoelSpeed thanks for this PR, this clarifications are really helpful!

fabriziopandini · 2025-06-17T15:52:08Z

contributors/devel/sig-architecture/api-conventions.md

 - The API server should not allow POSTing or PUTing a resource with this field
 unset.
+- They _typically_ do not use pointer types in the Go definition (e.g. `AnotherFlag SomeFlag`), though required fields where the zero value is a valid value must use pointer types, paired with an `omitempty` struct tag to avoid spurious null serializations.
+
+For more details on how to use pointers and `omitempty` with fields, see [Serialization of optional/required fields](#serialization-of-optionalrequired-fields).

 Using the `+optional` or the `omitempty` tag causes OpenAPI documentation to


q: should this (openAPI documentation) change now that we can have omitempty on required fields?

We will need to make sure that it respects +required tags. If the field doesn't have +required and has omitempty, then I think there are many tools that still assume optional and we shouldn't change that.

In the long run, we need to make sure all fields are marked as +optional xor +required explicitly

liggitt · 2025-06-24T14:16:37Z

contributors/devel/sig-architecture/api-conventions.md

+This is expected to change in the future and having the `+optional` comment tag is
+now required on new optional fields.


nit: maybe rephrase this to avoid interleaving optional ... required ... optional wording (even though it refers to different contexts)

Maybe something like this:

This is expected to change in the future, and new fields should explicitly set either an +optional or +required comment tag.

liggitt · 2025-06-24T14:17:28Z

contributors/devel/sig-architecture/api-conventions.md

+    B -- No --> D{Is the field optional, or required?};
+    D -- Optional --> E[Does the field have a built-in nil value?];
+    E -- Yes --> F[Do not use a pointer, use omitempty];
+    E -- no --> C;


Suggested change

E -- no --> C;

E -- No --> C;

liggitt · 2025-06-24T14:17:50Z

contributors/devel/sig-architecture/api-conventions.md

+    A[Start] --> B{Is the zero value a valid user choice?};
+    B -- Yes --> C[Use a pointer and omitempty];
+    B -- No --> D{Is the field optional, or required?};
+    D -- Optional --> E[Does the field have a built-in nil value?];


Suggested change

D -- Optional --> E[Does the field have a built-in nil value?];

D -- Optional --> E[Does the field type have a built-in nil value?];

liggitt · 2025-06-24T14:18:04Z

contributors/devel/sig-architecture/api-conventions.md

+graph TD;
+    A[Start] --> B{Is the zero value a valid user choice?};
+    B -- Yes --> C[Use a pointer and omitempty];
+    B -- No --> D{Is the field optional, or required?};


Suggested change

B -- No --> D{Is the field optional, or required?};

B -- No --> D{Is the field optional or required?};

liggitt · 2025-06-24T14:20:22Z

contributors/devel/sig-architecture/api-conventions.md

+    A[Start] --> B{Is the zero value a valid user choice?};
+    B -- Yes --> C[Use a pointer and omitempty];
+    B -- No --> D{Is the field optional, or required?};
+    D -- Optional --> E[Does the field have a built-in nil value?];


would it be simpler to inline the types which do have built-in nil values? "Does the field type have a built-in nil value (map or slice)?")

liggitt · 2025-06-24T14:23:29Z

contributors/devel/sig-architecture/api-conventions.md

+- When a field is required, and the zero value is not valid, a structured client who has not expressed an explicit choice will have their request rejected by the API server based on the invalid value, rather than the field being unset.
+  - For example, a string with a minimum length of 1; Validation would not understand if the field was unset, or set to the empty string deliberately, but would still reject the request because it did not meet the length requirements.
+  - Technically, using a pointer in these cases is also acceptable, but not advised as it makes coding more complex, and increases the risk of nil pointer exceptions.
+  - In these cases, not using `omitempty` provides the same result, but pollutes the marhsalled object with zero values and is not recommended.


Suggested change

- In these cases, not using `omitempty` provides the same result, but pollutes the marhsalled object with zero values and is not recommended.

- In these cases, not using `omitempty` provides the same result, but pollutes the marshaled object with zero values and is not recommended.

sbueringer · 2025-07-02T05:35:42Z

contributors/devel/sig-architecture/api-conventions.md

+
+- It can be difficult for implementors to anticipate all cases where an empty
+value might need to be distinguished from a zero value.
+- Structs are not omitted from encoder output even where `omitempty` is specified,


What about omitzero?

Omitzero should work, but as far as I know, we haven't tested this yet, or explored what would happen re-protobuf for built-in types. For now I'd rather not mention omitzero until we've had a chance to test it.

I'd see that as a follow up.

+1 to this -- we should be clear that "encoding" means a lot more than just JSON :)

sbueringer · 2025-07-02T05:39:47Z

contributors/devel/sig-architecture/api-conventions.md

+To determine whether a field should be a pointer, consider the following:
+
+```mermaid
+graph TD;


This is not in sync with Kal with whenrequired setting, right?

Correct. KAL's optionalfields implementation of WhenRequired is intended for CRD authors where the behaviour differs slightly.

For CRDs, because the validation of required vs optional happens at the openapi stage, and for any field where the zero value is not valid, openapi would pick this up before a structured go client were to see the object, we can safely assume for CRDs that for a field where the zero value isn't valid, that the user did not specify the zero value when we see the zero value in the Go struct.

With built-in types, all of the validation above is done using Go. And as such, we must be able to distinguish between unset and the zero value to be able to enforce that the zero value is not valid, hence a pointer is always required in these cases.

I think we should probably explain this somewhere as an addendum to this advice.

sbueringer · 2025-07-02T13:03:06Z

contributors/devel/sig-architecture/api-conventions.md

@@ -847,8 +847,8 @@ See https://github.com/kubernetes/kubernetes/issues/34641.

 Note that for backward compatibility, any field that has the `omitempty` struct
 tag, and is not explicitly marked as `+required`, will be considered to be optional.
-This is expected to change in the future and having the `+optional` comment tag is
-now required on new optional fields.
+This is expected to change in the future, and new fields should explicitly set eith


nit: eith => either

sbueringer · 2025-07-02T13:03:39Z

contributors/devel/sig-architecture/api-conventions.md

@@ -893,10 +893,22 @@ There are several implications of the above:
 - When a field is required, and the zero value is not valid, a structured client who has not expressed an explicit choice will have their request rejected by the API server based on the invalid value, rather than the field being unset.
  - For example, a string with a minimum length of 1; Validation would not understand if the field was unset, or set to the empty string deliberately, but would still reject the request because it did not meet the length requirements.
  - Technically, using a pointer in these cases is also acceptable, but not advised as it makes coding more complex, and increases the risk of nil pointer exceptions.
-  - In these cases, not using `omitempty` provides the same result, but pollutes the marhsalled object with zero values and is not recommended.
+  - In these cases, not using `omitempty` provides the same result, but pollutes the marhsaled object with zero values and is not recommended.


typo: marhsaled

liggitt

a few tweaks, looks good overall

liggitt · 2025-07-02T15:14:16Z

contributors/devel/sig-architecture/api-conventions.md

+
+#### Serialization in CRDs
+
+When CRDs are admitted by the API server, openapi validation is applied to the object _prior_ to any structured client observing the object.


Suggested change

When CRDs are admitted by the API server, openapi validation is applied to the object _prior_ to any structured client observing the object.

When custom resources are admitted by the API server, openapi validation is applied to the object _prior_ to any structured client observing the object.

liggitt · 2025-07-02T15:14:31Z

contributors/devel/sig-architecture/api-conventions.md

+- For structs, the zero value can only be valid when the struct has no required fields, and does not require at least one property to be set.
+  - Required structs should use `omitzero` to avoid marshalling the zero value.
+
+#### Serialization in CRDs


Suggested change

#### Serialization in CRDs

#### Serialization of custom resources

liggitt · 2025-07-02T15:14:56Z

contributors/devel/sig-architecture/api-conventions.md

-which is messy;
- having a pointer consistently imply optional is clearer for users of the Go
-language client, and any other clients that use corresponding types
+For a field where the zero value is not valid, the openapi validation will reject the object if the field is set, and is set to the zero value,


Suggested change

For a field where the zero value is not valid, the openapi validation will reject the object if the field is set, and is set to the zero value,

For a field where the zero value is not valid, the openapi validation will reject the object if the field is present and set to the zero value,

liggitt · 2025-07-02T15:15:30Z

contributors/devel/sig-architecture/api-conventions.md


-Therefore, we ask that pointers always be used with optional fields that do not
-have a built-in `nil` value.
+This means that there is no need to be able to distinguish, in a CRD, between unset and the zero value for fields where the zero value is not valid.


Suggested change

This means that there is no need to be able to distinguish, in a CRD, between unset and the zero value for fields where the zero value is not valid.

This means that there is no need to distinguish in a custom resource between unset and the zero value for fields where the zero value is not valid.

liggitt · 2025-07-02T15:25:05Z

contributors/devel/sig-architecture/api-conventions.md

+    A[Start] --> B{Is the zero value a valid user choice?};
+    B -- Yes --> C[Use a pointer and omitempty];
+    B -- No --> D{Is the field optional or required?};
+    D -- Optional --> E[Does the field type have a built-in nil value (map or slice)?];


looks like the (map or slice)? bit is confusing mermaid... might need to escape that?

If you quote the whole string this is fixed

liggitt · 2025-07-02T15:49:45Z

/lgtm
/approve

dims · 2025-07-02T15:52:46Z

tagging other chairs

cc @derekwaynecarr @johnbelamaric

dims · 2025-07-02T15:57:35Z

/approve

k8s-ci-robot · 2025-07-02T15:57:45Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, JoelSpeed, liggitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~contributors/devel/sig-architecture/OWNERS~~ [dims]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

JoelSpeed · 2025-07-02T21:36:50Z

/hold cancel

I think we are good to move forward

thockin · 2025-07-02T23:55:01Z

contributors/devel/sig-architecture/api-conventions.md

+When the field type has a built-in `nil` value, such as a map or a slice, and
+your use case means that you need to be able to distinguish between
+"field not set" and "field set to an empty value", you should use a pointer to
+the type, even though it has a built-in `nil` value.


AFAIK we do not have any pointer-to-{slice,map} fields and I have told people in the past that we DO NOT want them. This makes it sound like it would be OK, but I don't think it would (I strongly suspect some codegen would break). I was actually a bit surprised that JSON unmarshal handles it properly.

One use case I have seen is *[]corev1.Taint. Where the use case will default "I have no opinion" to include a set of default taints, but, if you specifically do not want those taints, it documents that you should explicitly provide an empty list [] for the field.

Do you think that would not actually be possible then? What would you recommend instead for this use case?

I suspect it doesn't work as described. We tried to do this in network policy and gave up because it did not work.

The only answer I know, and the way we did it in straight proto (caveat: it's been a while) is to put a (pointer to) struct in between. Nil struct means default. Non-nul means the list is present. All languages can decode that into something intelligible.

Not sure about builtin types, for CRDs it looks like controller-gen works (we generate deep copy, conversion and CRD YAMLs). I just replaced a custom MarshalJSON func for []corev1.Taint (to preserve []) with *[]corev1.Taint and it worked out of the box

thockin · 2025-07-02T23:56:55Z

contributors/devel/sig-architecture/api-conventions.md

+
+- It can be difficult for implementors to anticipate all cases where an empty
+value might need to be distinguished from a zero value.
+- Structs are not omitted from encoder output even where `omitempty` is specified,


+1 to this -- we should be clear that "encoding" means a lot more than just JSON :)

thockin · 2025-07-02T23:58:19Z

contributors/devel/sig-architecture/api-conventions.md

+    D -- Required --> F
+```
+There are several implications of the above:
+- For lists and maps where the zero valid is a valid user choice, this means that `[]` and `{}` have a semantically different meaning than unset, in this case it is appropriate to use `*[]T` or `*map[T]S` respectively.


See comment above - I am not sure we want to allow this. IIRC protobuf doesn't have a way to represent this without an intermediate struct.

Hrmm... you're probably right about proto-persisted things.

For typed clients that use go but are backed on the server by a CRD, that means that serialization is always json and this is representable. I agree a pointer to a map or slice is weird. I think it's useful to describe this implication / edge, but would be fine discouraging making use of it ("avoid map or slice fields where {} or [] is valid and treated differently from an absent value")

Have one use case in #8486 (comment), but yes, when I've thought through this before, I've never worked out an issue with doing this in CRDs. If it's an issue for proto, then perhaps the right thing to do here is update the wording to say never do this for built-in (?) types, but it can work for custom resources?

perhaps the right thing to do here is update the wording to say never do this for built-in (?) types

There are three areas rationale is based on:

client-side behavior... making sure a client can transmit on the wire what it means

server-side validation / defaulting behavior ... making sure a server can distinguish what the client sent in ways that let it validate and default sensibly

server-side persistence / round-tripping behavior ... making sure a server can persist distinctions that matter

2 and 3 are definitely different for custom-resources vs built-in/server-typed resources, and custom resources are actually more predictable since they store as json and don't conflate absent and present-with-zero-value on the server side. I guess we could branch the guidance early on if we think it would lead to different/simpler/better recommendations for one case or the other.

I would argue that the word "pointer" has no real meaning in CRD and in fact our API docs should describe a language-neutral data model. We happen to use Go to implement that model, and while Go has the concept of array, nil-slice, empty-slice, and pointer-to-slice, those are not part of our data model.

The question then is whether CRD should be able to do things that proto can't, because proto is static and CRD less so? I am fairly sure we could put tag numbers into CRDs and synthesize a proto descriptor, but we don't.

I think our data model should be limited to the common subset (basically "what proto can do"), for CRD /and/ built-in, otherwise we end up with divergent API patterns depending on implementation. Blech.

We support list (aka repeated) fields. They can have 0 or more items. They are not present or absent, they just have a size.

We happen to use Go to implement that model, and while Go has the concept of array, nil-slice, empty-slice, and pointer-to-slice, those are not part of our data model.

Do we have any data on how many custom resource APIs for K8s are written not in Go? My assumption has always been that the majority are, and therefore having guidance that applies to the majority, and helps prevent them from making serialization mistakes has value. Perhaps the missing part is that we don't talk about these being Go specific in the guidance?

k8s-ci-robot added the cncf-cla: yes label Jun 12, 2025

k8s-ci-robot requested review from dims and jbeda June 12, 2025 09:51

k8s-ci-robot added area/developer-guide sig/architecture sig/contributor-experience size/XS labels Jun 12, 2025

sbueringer reviewed Jun 12, 2025

View reviewed changes

k8s-ci-robot added the do-not-merge/hold label Jun 12, 2025

thockin reviewed Jun 12, 2025

View reviewed changes

JoelSpeed force-pushed the update-required-fields-conventions branch from c2ee563 to 8856289 Compare June 13, 2025 13:13

k8s-ci-robot added size/M and removed size/XS labels Jun 13, 2025

JoelSpeed force-pushed the update-required-fields-conventions branch 2 times, most recently from 22f7099 to a40a583 Compare June 13, 2025 13:39

JoelSpeed mentioned this pull request Jun 13, 2025

Discourage usage of nullable on API types #8488

Open

fabriziopandini reviewed Jun 17, 2025

View reviewed changes

liggitt reviewed Jun 24, 2025

View reviewed changes

sbueringer reviewed Jul 2, 2025

View reviewed changes

JoelSpeed force-pushed the update-required-fields-conventions branch from 64c654f to 566dd72 Compare July 2, 2025 13:10

liggitt reviewed Jul 2, 2025

View reviewed changes

Update guidance on optional/required field serialization

48f3ac9

JoelSpeed force-pushed the update-required-fields-conventions branch from 566dd72 to 48f3ac9 Compare July 2, 2025 15:48

k8s-ci-robot assigned liggitt Jul 2, 2025

k8s-ci-robot added the lgtm label Jul 2, 2025

k8s-ci-robot added the approved label Jul 2, 2025

k8s-ci-robot removed the do-not-merge/hold label Jul 2, 2025

k8s-ci-robot merged commit 33bdd60 into kubernetes:master Jul 2, 2025
3 checks passed

thockin reviewed Jul 2, 2025

View reviewed changes

		This is expected to change in the future and having the `+optional` comment tag is
		now required on new optional fields.

	D -- Optional --> E[Does the field have a built-in nil value?];
	D -- Optional --> E[Does the field type have a built-in nil value?];

	B -- No --> D{Is the field optional, or required?};
	B -- No --> D{Is the field optional or required?};

	- In these cases, not using `omitempty` provides the same result, but pollutes the marhsalled object with zero values and is not recommended.
	- In these cases, not using `omitempty` provides the same result, but pollutes the marshaled object with zero values and is not recommended.


		#### Serialization in CRDs

		When CRDs are admitted by the API server, openapi validation is applied to the object _prior_ to any structured client observing the object.

	When CRDs are admitted by the API server, openapi validation is applied to the object _prior_ to any structured client observing the object.
	When custom resources are admitted by the API server, openapi validation is applied to the object _prior_ to any structured client observing the object.

	#### Serialization in CRDs
	#### Serialization of custom resources

	For a field where the zero value is not valid, the openapi validation will reject the object if the field is set, and is set to the zero value,
	For a field where the zero value is not valid, the openapi validation will reject the object if the field is present and set to the zero value,

	This means that there is no need to be able to distinguish, in a CRD, between unset and the zero value for fields where the zero value is not valid.
	This means that there is no need to distinguish in a custom resource between unset and the zero value for fields where the zero value is not valid.

Update guidance on required field serialization #8486

Update guidance on required field serialization #8486

Conversation

JoelSpeed commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JoelSpeed commented Jun 12, 2025

Nullable

String

Integer/Float

Bool

Lists

Maps

Objects

Uh oh!

sbueringer Jun 12, 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!

sbueringer Jun 13, 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!

JoelSpeed commented Jun 12, 2025

Uh oh!

liggitt commented Jun 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fabriziopandini commented Jun 17, 2025

Uh oh!

fabriziopandini Jun 17, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

JoelSpeed commented Jun 12, 2025 •

edited

Loading

sbueringer Jun 12, 2025 •

edited

Loading

sbueringer Jun 13, 2025 •

edited

Loading

fabriziopandini Jun 17, 2025 •

edited

Loading

sbueringer Jul 3, 2025 •

edited

Loading