Add Cloud Events support to Spring Integration #10448

cppwfs · 2025-09-26T20:28:11Z

Introduces Cloud Events v1.0 specification support including message converters, transformers, and utilities.

Key components added:

CloudEventMessageConverter for message format conversion
ToCloudEventTransformer for transforming messages to Cloud Events
MessageBinaryMessageReader/Writer for binary format handling
CloudEventProperties for configuration management
Header pattern matching utilities for flexible event mapping
Add reference docs and what's-new paragraph

artembilan

Left some at a glance review.

Thank you!

build.gradle

...src/main/java/org/springframework/integration/cloudevents/v1/CloudEventMessageConverter.java

...g/springframework/integration/cloudevents/v1/transformer/CloudEventMessageConverterTest.java

src/reference/antora/modules/ROOT/pages/whats-new.adoc

artembilan

Sorry for a lengthy review and some doubts I've expressed.

I addition, what are your thoughts about content of this package in Spring Cloud Function: https://github.com/spring-cloud/spring-cloud-function/tree/main/spring-cloud-function-context/src/main/java/org/springframework/cloud/function/cloudevent ?

I mean transformer does the trick indeed, but only from an integration flow context.
How about the way to be able to construct CloudEvent programmatically?
Or just existing SDK API is enough to deal with?

...ts/src/main/java/org/springframework/integration/cloudevents/CloudEventMessageConverter.java

...ation/cloudevents/transformer/strategies/cloudeventconverter/CloudEventMessageConverter.java

...ation/cloudevents/transformer/strategies/cloudeventconverter/MessageBinaryMessageReader.java

...pringframework/integration/cloudevents/v1/transformer/ToCloudEventTransformerExtensions.java

...a/org/springframework/integration/cloudevents/v1/transformer/utils/HeaderPatternMatcher.java

...java/org/springframework/integration/cloudevents/v1/transformer/ToCloudEventTransformer.java

.../main/java/org/springframework/integration/cloudevents/transformer/CloudEventProperties.java

...loudevents/src/main/java/org/springframework/integration/cloudevents/CloudEventsHeaders.java

src/reference/antora/modules/ROOT/pages/cloudevents/cloudevents-transform.adoc

...ts/src/main/java/org/springframework/integration/cloudevents/CloudEventMessageConverter.java

...loudevents/src/main/java/org/springframework/integration/cloudevents/CloudEventsHeaders.java

...ts/src/main/java/org/springframework/integration/cloudevents/MessageBinaryMessageReader.java

...s/src/main/java/org/springframework/integration/cloudevents/MessageBuilderMessageWriter.java

...g/springframework/integration/cloudevents/transformer/ToCloudEventTransformerExtensions.java

.../java/org/springframework/integration/cloudevents/transformer/strategies/FormatStrategy.java

...t/java/org/springframework/integration/cloudevents/transformer/CloudEventPropertiesTest.java

build.gradle

cppwfs · 2025-10-06T19:11:48Z

For now hold off on a review. I'm writing up some questions for some guidance on some of the issues you raised in the last 2 reviews.

.../java/org/springframework/integration/cloudevents/transformer/strategies/FormatStrategy.java

...s/src/main/java/org/springframework/integration/cloudevents/MessageBuilderMessageWriter.java

...loudevents/src/main/java/org/springframework/integration/cloudevents/CloudEventsHeaders.java

build.gradle

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

...va/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformerTests.java

src/reference/antora/modules/ROOT/nav.adoc

src/reference/antora/modules/ROOT/pages/cloudevents-transform.adoc

src/reference/antora/modules/ROOT/pages/whats-new.adoc

src/reference/antora/modules/ROOT/pages/cloudevents-transform.adoc

...va/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformerTests.java

artembilan

Sorry for lengthy review: too many concerns.

Please, consider to rebase your branch to the latest main.
And take into account that it is already 7.1.

Thanks

build.gradle

...java/org/springframework/integration/cloudevents/transformer/CloudEventMessageConverter.java

...ava/org/springframework/integration/cloudevents/transformer/MessageBuilderMessageWriter.java

...n/java/org/springframework/integration/cloudevents/transformer/ToCloudEventsTransformer.java

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

src/reference/antora/modules/ROOT/pages/whats-new.adoc

artembilan

I see you have addressed everything from the previous review, but probably just locally.
Please, push it into PR with rebase to the latest main.
This way I might review it again before Monday.

Thanks

artembilan

Sorry for such a lengthy review before New Year 😄 .

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

artembilan · 2025-12-30T16:06:15Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+	 * Create a ToCloudEventTransformer.
+	 * @param extensionPatterns patterns to evaluate whether message headers should be added as extensions
+	 *                          to the CloudEvent
+	 * @since 7.1


This @since on methods is redundant since all of them have been introduced together with the class.

artembilan · 2025-12-30T16:08:14Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+	protected void onInit() {
+		super.onInit();
+		this.evaluationContext = ExpressionUtils.createStandardEvaluationContext(getBeanFactory());
+		if (this.sourceExpression == null) {  // in the case the user sets the value prior to onInit.


Please, remove the comment.
It does not give any value.
Plus, it sounds like does not reflect reality: the condition is about null, but sentence in comment says something opposite.

artembilan · 2025-12-30T16:08:59Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+			String appName = applicationContext.getEnvironment().getProperty("spring.application.name");
+			logger.warn("'spring.application.name' is not set. " +
+					"CloudEvent source URIs will use 'null' as the application name. " +
+					"Consider setting 'spring.application.name'");


I think this warning has to be conditional on appName == null

artembilan · 2025-12-30T16:10:57Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+		String type = this.typeExpression.getValue(this.evaluationContext, message, String.class);
+		MessageHeaders headers = message.getHeaders();
+		MessageHeaderAccessor accessor = new MessageHeaderAccessor(message);
+		MimeType mimeType = accessor.getContentType();


Please, consider to use StaticMessageHeaderAccessor.getContentType() instead.
That way we won't have an extra MessageHeaderAccessor volatile object.

artembilan · 2025-12-30T16:57:06Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

+
+==== Extension Patterns
+
+The extensionPatterns constructor parameter is a vararg of ``String``s.


No need to wrap into code snippet.
Just say of strings and that's enough.
Really this sentence does not emphasize about exactly String object logic and API.

artembilan · 2025-12-30T16:58:48Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

+    .withHeader(MessageHeaders.CONTENT_TYPE, "application/octet-stream")
+    .build();
+// Transformer with extension patterns
+ToCloudEventTransformer transformer = new ToCloudEventTransformer();


The comment about does not reflect this constructor behavior.

artembilan · 2025-12-30T17:00:05Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

+// Input message with headers
+Message<byte[]> inputMessage = MessageBuilder
+    .withPayload("Hello CloudEvents".getBytes(StandardCharsets.UTF_8))
+    .withHeader(MessageHeaders.CONTENT_TYPE, "application/octet-stream")


Well, I would say this is text/plain.
The octet-stream is too general and could be used somewhere else.
But having just text and ignoring its respective content type, might lead to a wrong impression.

Do we want to provide the output of the transformation to add clarification?

Yes, we want an output format explained somewhere, but that is not a concern of this code example.
What I mean here that Hello CloudEvents is a text/plain, not an application/octet-stream.
That's only a change I want to see in this example.
Otherwise it is misleading.

artembilan · 2025-12-30T17:01:18Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

+[[eventformats]]
+==== EventFormats
+
+The `ToCloudEventTransformer` uses ``EventFormat``s to serialize the CloudEvent into the message's payload.


You need to say more about contentType header and how it is used for EventFormat search.
I also don't see anywhere that we mention the output contentType and those ce- attributes produced by our transformer.
That is really most important part of the transformer: give a message with some data and get back a message with that data but in CloudEvents format.
And that could be done by the EventFormat delegation or flattening into message headers.
Looks like that is missing in this doc.

This was my request about the transformer output.
The configuration explanation is good, but what is the result of that transformation.
That's is exactly what users are going to deal with.

artembilan · 2025-12-30T17:07:32Z

...va/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformerTests.java

+
+		assertThat(result).isNotNull();
+		assertThat(result).isInstanceOf(Message.class);
+		return (Message<byte[]>) result;


This whole message is redundant.
We simply can use Transformer.transform() API in all those tests.

Introduces Cloud Events v1.0 specification support including message converters, transformers, and utilities. Key components added: - CloudEventMessageConverter for message format conversion - ToCloudEventTransformer for transforming messages to Cloud Events - MessageBinaryMessageReader/Writer for binary format handling - CloudEventProperties for configuration management - Header pattern matching utilities for flexible event mapping - Add reference docs and what's-new paragraph

Remove v1 subpackage and flatten the CloudEvents package hierarchy. Introduce strategy pattern for format conversion to replace enum-based approach, improving extensibility and reduce dependencies. Key changes: - Move all classes from cloudevents.v1 to cloudevents base package - Remove optional format dependencies (JSON, XML, Avro) from build - Replace `ConversionType` enum with `FormatStrategy` interface - Add `CloudEventMessageFormatStrategy` as default implementation - Inline `HeaderPatternMatcher` logic into `ToCloudEventTransformerExtensions` - Add `@NullMarked` package annotations and `@Nullable` throughout - Document `targetClass` parameter behavior in `CloudEventMessageConverter` - Split transformer tests for better organization and coverage - Update component type identifier to "ce:to-cloudevents-transformer" - Remove unnecessary docs from package-info

- Simplify the CloudEvent transformer by consolidating configuration directly into ToCloudEventTransformer class rather than using separate configuration objects - Remove CloudEventProperties and ToCloudEventTransformerExtensions classes to reduce abstraction layers and improve maintainability - Make MessageBinaryMessageReader package-private and convert CloudEventMessageConverter methods to static where possible - Move extension filtering logic into a private inner class within the transformer - Remove CloudEventsHeaders class and CE_PREFIX constant as the prefix is no longer used as a configurable value

Replace custom CloudEvent converter infrastructure with direct CloudEvents SDK format implementations. Key changes: - Replace `FormatStrategy` pattern-based approach with direct `EventFormatProvider` integration from CloudEvents SDK - Remove custom converter classes (`CloudEventMessageConverter`, `MessageBinaryMessageReader`, `MessageBuilderMessageWriter`) - Simplify transformer to use Expression-based configuration for all CloudEvent attributes (id, source, type, dataSchema, subject) - Add validation for required CloudEvent attributes with clear error messages when expressions evaluate to null or empty values - Update documentation to reflect Expression-based API and byte[] payload requirement - Consolidate tests by removing coverage for deleted converter infrastructure

The previous extension extraction mechanism using `Expression` arrays and a separate `ExtensionsExtractor` interface was overly complex for the simple use case of pattern matching header names. This change simplifies the API by: - Removing the `ExtensionsExtractor` interface and implementations - Replacing `Expression`-based extension configuration with simple String pattern matching in the transformer constructor - Updating all javadocs to use imperative voice per Spring conventions (e.g., "Converts messages" instead of "A transformer that converts messages") - Making default value descriptions more concise (e.g., "Defaults to null" instead of "Default Expression evaluates to a null") - Add extensionPattern match logic

Enable CloudEvents to be sent with headers instead of requiring structured format serialization. This provides flexibility when integrating with systems that don't support CloudEvents structured formats. Introduce `CloudEventMessageConverter` to handle CloudEvent to Message conversion, utilizing the CloudEvents SDK's `MessageWriter` abstraction. Add `noFormat` configuration option to `ToCloudEventsTransformer`. When enabled and no `EventFormat` is available for the content type, CloudEvent attributes are written to message headers with configurable prefix (defaults to "ce-"). Add `cloudEventPrefix` property to customize the header prefix when `noFormat` is set to true, supporting different integration scenarios. Add test coverage for binary content mode including extension handling, custom prefixes, and validation that original headers are preserved alongside CloudEvent headers.

Update javadoc comments in `CloudEventMessageConverter` and `ToCloudEventsTransformer` to improve clarity and readability. Enhance the CloudEvents reference documentation to better explain how extensions are populated using pattern matching instead of SpEL expressions. Changes include: - Clarify `CloudEventMessageConverter` class-level javadoc - Improve `isNoFormat()` and `setNoFormat()` method documentation - Update reference docs to reflect extension patterns approach - Fix minor formatting issues (double spaces)

This commit updates the CloudEvents module from version 7.0 to 7.1 by consolidating classes and improving the architecture. The previous design separated the CloudEvent conversion logic across multiple classes (`CloudEventMessageConverter` and `MessageBuilderMessageWriter`), which added unnecessary complexity for what is fundamentally a single transformation operation. Key changes: - Removed `CloudEventMessageConverter` and `MessageBuilderMessageWriter` as standalone classes - Consolidated conversion logic into `ToCloudEventTransformer` by making `MessageBuilderMessageWriter` a private static inner class - Renamed `ToCloudEventsTransformer` to `ToCloudEventTransformer` to match naming conventions (singular form) - Removed Avro dependencies and associated tests that were no longer needed - Changed `setNoFormat()` to `setFailOnNoFormat()` for clearer semantics - Enhanced null safety by removing `@Nullable` from setters that should always have values - Re-add isFailOnNoFormat logic and tests that was removed - Improved documentation and added defensive copying for the `extensionPatterns` array parameter - Updated tests to reflect the new class names and structure - Rebased The refactoring reduces the public API surface while maintaining all functionality, making the code easier to understand and maintain.

Address multiple improvements to the CloudEvents transformer module: - Reorganize constructor ordering in `ToCloudEventTransformer` to put the no-arg constructor first, following Java conventions - Remove unused Avro test dependency from build.gradle - Improve content type handling using `MessageHeaderAccessor` and `MimeType` instead of direct String extraction - Refactor extension processing to use `Map.copyOf()` for immutability - Rename `ToCloudEventTransformerExtensions` to singular `ToCloudEventTransformerExtension` for consistency - Inline constant strings for specversion and datacontenttype keys - Fix content type header to use `eventFormat.serializedContentType()` instead of the input message's content type - Simplify binary mode message creation by constructing `MessageHeaders` directly - Update test assertions to match null appName behavior - Enhance documentation clarity: improve wording, fix grammar, capitalize table entries, and add examples for content types - Restructure documentation sections for better readability - Update `MessageBuilderMessageWriter` to implement `CloudEventWriterFactory` instead of `MessageWriter` The message writer had default functions unused by the read method. - Remove unused `setEvent()` method and `dataContentTypeKey` field from `MessageBuilderMessageWriter` - Apply Spring code convention

artembilan · 2025-12-30T21:42:27Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+
+	private static final String DEFAULT_PREFIX = "ce-";
+
+	private static final EventFormatProvider eventFormatProvider = EventFormatProvider.getInstance();


If this is static final then it has to be in upper case.
It is a constant then, therefore respective naming convention.

artembilan · 2025-12-31T15:22:39Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+					.setHeader(MessageHeaders.CONTENT_TYPE, eventFormat.serializedContentType())
+					.build();
+		}
+		HashMap<String, Object> messageMap = new HashMap<>(headers);


I think putting the contentType header could be hidden in the MessageBuilderMessageWriter.
Perhaps in its end() implementation.
That way we would not need to wrap headers into a new map.

artembilan · 2025-12-31T15:30:20Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+				.withExtension(extensions)
+				.build();
+
+		EventFormat eventFormat = eventFormatProvider.resolveFormat(contentType);


Since we have realized that provider is based on exactly cloudevents+ content types, then we cannot rely on our common types.
I think we should come back to the idea about an EventFormat injection into this our transformer.
(My apologies that I misled to the EventFormatProvider).

We probably still can use an EventFormatProvider, however not against standard contentType header, but with some custom SpEL expression.
This way the logic would be:

Use injected EventFormat (if any)

Resolve eventFormatContentTypeExpression (if any)

Call EventFormatProvider for the previous expression result.

If no such a format, fail if failOnNoFormat

Still use an input contentType header as a dataContentType in the CloudEvent

Still populate a proper output contentType from the EventFormat or standard one in the MessageBuilderMessageWriter

WDYT?

artembilan · 2025-12-31T15:32:19Z

...va/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformerTests.java

+		assertThat(cloudEvent.getData().toBytes()).isEqualTo(PAYLOAD);
+		assertThat(cloudEvent.getSource().toString()).isEqualTo("/spring/null.transformerWithNoExtensions");
+		assertThat(cloudEvent.getDataSchema()).isNull();
+		assertThat(cloudEvent.getDataContentType()).isEqualTo(JsonFormat.CONTENT_TYPE);


Yes, the current behavior reflects whatever is possible with the current implementation.
However that is not what we want with our transformer.
See my suggestion above about an EventFormat injection and so on.

artembilan · 2025-12-31T15:34:06Z

...va/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformerTests.java

+
+	@Test
+	void emptyStringPayloadHandling() {
+		Message<byte[]> message = createBaseMessage("".getBytes(), "application/cloudevents+json").build();


Just to close the loop: in some other comment about I've suggested an EventFormat injection or respective eventFormatContentTypeExpression instead of this not fully flexible logic against a input contentType header.

artembilan · 2025-12-31T15:36:33Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

+| "spring.message"
+
+| `dataContentType`
+| The contentType of the message, defaults to `application/octet-stream`.


Yes, examples here you provide are exactly what I would expect sending a text/json in the contentType to our transformer. So, this value would be copied to the dataContentType attribute of the cloud event.
Meanwhile the output contentType header would be applicaiton/cloudevents (or with + if format is involved).

artembilan · 2025-12-31T15:38:21Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

+// Input message with headers
+Message<byte[]> inputMessage = MessageBuilder
+    .withPayload("Hello CloudEvents".getBytes(StandardCharsets.UTF_8))
+    .withHeader(MessageHeaders.CONTENT_TYPE, "application/octet-stream")


Yes, we want an output format explained somewhere, but that is not a concern of this code example.
What I mean here that Hello CloudEvents is a text/plain, not an application/octet-stream.
That's only a change I want to see in this example.
Otherwise it is misleading.

artembilan · 2025-12-31T15:39:37Z

src/reference/antora/modules/ROOT/pages/cloudevents.adoc

+[[eventformats]]
+==== EventFormats
+
+The `ToCloudEventTransformer` uses ``EventFormat``s to serialize the CloudEvent into the message's payload.


This was my request about the transformer output.
The configuration explanation is good, but what is the result of that transformation.
That's is exactly what users are going to deal with.

Code quality improvements: - Remove unnecessary `@since 7.1` tags from internal javadocs - Fix NullAway suppressions by adding proper null checks - Replace `MessageHeaderAccessor` with `StaticMessageHeaderAccessor` - Eliminate redundant field initialization (failOnNoFormat defaults to false) - Simplify extension comparison using `Boolean.TRUE.equals()` - Remove unnecessary Map.copyOf() in extension implementation - Fix app name null check to only warn when actually null Test refactoring: - Make test helper methods static for better encapsulation - Rename test methods to clearly indicate content type being tested - Separate JSON format vs application/json content type test cases - Add explicit verification for application/* content types - Improve test assertions using containsEntry() instead of get() - Remove unnecessary null checks in tests - Consolidate duplicate test setup code Documentation: - Add package-info.java descriptions for cloudevents packages - Update reference documentation for extension patterns clarity

artembilan · 2025-12-31T16:18:42Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+	private Map<String, Object> getCloudEventExtensions(MessageHeaders headers) {
+		Map<String, Object> cloudEventExtensions = new HashMap<>();
+		Boolean patternResult;
+		String headerKey;


These variables really belong to the loop scope below.
Why would you declare them outside of the loop?

artembilan · 2025-12-31T16:20:29Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+ * Perform attribute and extension mapping based on {@link Expression}s.
+ *
+ * @author Glenn Renfro
+ * @since 7.1


Missed blank line after @author

artembilan · 2025-12-31T16:22:28Z

...in/java/org/springframework/integration/cloudevents/transformer/ToCloudEventTransformer.java

+
+/**
+ * Convert messages to CloudEvent format.
+ * Perform attribute and extension mapping based on {@link Expression}s.


OK with attribute.
But extension is not does by expression.
Please, consider to revise this Javadoc to reflect reality about the transformer logic.
I guess we can leave EventFormat out of this for now, since we don't have a final solution yet.
But extensionPatterns could be already explained in this Javadocs properly.

cppwfs requested a review from artembilan September 26, 2025 20:28

cppwfs force-pushed the SI-cloud-events branch 2 times, most recently from 03d1f51 to 02a1329 Compare September 26, 2025 20:47

artembilan requested changes Sep 26, 2025

View reviewed changes

artembilan requested changes Sep 29, 2025

View reviewed changes

cppwfs force-pushed the SI-cloud-events branch 2 times, most recently from cabc5e5 to d14c5f8 Compare October 6, 2025 15:32

artembilan requested changes Oct 6, 2025

View reviewed changes

build.gradle Show resolved Hide resolved

artembilan requested changes Oct 6, 2025

View reviewed changes

.../java/org/springframework/integration/cloudevents/transformer/strategies/FormatStrategy.java Outdated Show resolved Hide resolved

artembilan requested changes Oct 7, 2025

View reviewed changes

...s/src/main/java/org/springframework/integration/cloudevents/MessageBuilderMessageWriter.java Outdated Show resolved Hide resolved

...loudevents/src/main/java/org/springframework/integration/cloudevents/CloudEventsHeaders.java Outdated Show resolved Hide resolved

cppwfs force-pushed the SI-cloud-events branch from d14c5f8 to d8989f9 Compare October 7, 2025 21:38

cppwfs force-pushed the SI-cloud-events branch from d8989f9 to be0fa17 Compare October 16, 2025 16:35

artembilan requested changes Oct 16, 2025

View reviewed changes

cppwfs force-pushed the SI-cloud-events branch from be0fa17 to d115df2 Compare November 5, 2025 14:32

cppwfs added the type: enhancement label Nov 5, 2025

cppwfs force-pushed the SI-cloud-events branch from d115df2 to 23379aa Compare November 24, 2025 14:44

artembilan requested changes Dec 18, 2025

View reviewed changes

artembilan requested changes Dec 26, 2025

View reviewed changes

cppwfs force-pushed the SI-cloud-events branch from 23379aa to 3db880e Compare December 26, 2025 19:26

cppwfs added this to the 7.1.0-M1 milestone Dec 29, 2025

artembilan requested changes Dec 30, 2025

View reviewed changes

cppwfs added 6 commits December 30, 2025 14:08

cppwfs added 3 commits December 30, 2025 14:08

artembilan requested changes Dec 30, 2025

View reviewed changes

artembilan requested changes Dec 31, 2025

View reviewed changes

cppwfs force-pushed the SI-cloud-events branch from a4ae49a to af2dbf8 Compare December 31, 2025 15:46

artembilan requested changes Dec 31, 2025

View reviewed changes


		==== Extension Patterns

		The extensionPatterns constructor parameter is a vararg of ``String``s.


		private static final String DEFAULT_PREFIX = "ce-";

		private static final EventFormatProvider eventFormatProvider = EventFormatProvider.getInstance();

Add Cloud Events support to Spring Integration #10448

Are you sure you want to change the base?

Add Cloud Events support to Spring Integration #10448

Conversation

cppwfs commented Sep 26, 2025

Uh oh!

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

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cppwfs commented Oct 6, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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