feat(schema): phase 17 - Remove AvroSchemaUtils usage (part 1) #17535

voonhous · 2025-12-09T16:49:11Z

Describe the issue this Pull Request addresses

Reference issue: #14282

This PR focuses on migrating usages of AvroSchemaUtils to the internal HoodieSchema abstraction and HoodieSchemaUtils.

Key Changes:

Migration: Migrated logic in key write/read paths (e.g., HoodieTable, HoodieWriteHandle, HoodieRowParquetWriteSupport) to use HoodieSchema and HoodieSchemaCompatibility.
Full Qualification: For classes where migration was not immediately feasible, calls to AvroSchemaUtils static functions have been fully qualified. This explicitly marks technical debt and makes these usages easily searchable for future refactoring.
Utility Enhancements: Added necessary bridge methods to HoodieSchemaUtils and HoodieSchemaCompatibility to support HoodieSchema objects directly.

Classes NOT included in migration (Fully Qualified)

The following classes retain AvroSchemaUtils usage but are now fully qualified:

AvroRecordContext
TestAvroSchemaUtils
AvroSchemaUtils (Self)
AvroSchemaComparatorForRecordProjection
HoodieAvroUtils
HoodieSchemaCompatibility
MissingSchemaFieldException
HoodieSchemaUtils
HiveAvroSerializer
HiveTypeUtils
SchemaBackwardsCompatibilityException
AvroSchemaRepair
TestAvroSchemaRepair
TestHoodieSchemaCompatibility (For consistency testing)

Classes Addressed in dependent PR #17536

FileGroupReaderSchemaHandler
OrderingValueEngineTypeConverter
ParquetRowIndexBasedSchemaHandler
HoodieAvroReaderContext

Specific Ignored Usages (getAvroRecordQualifiedName)

The following classes ignore AvroSchemaUtils.getAvroRecordQualifiedName:

BaseHoodieWriteClient
HoodieCatalog
HoodieHiveCatalog
HoodieTableFactory
StreamSync
TestHoodieTableFactory

Summary and Changelog

This PR is a refactoring effort to improve schema abstraction within Hudi. By moving away from raw Avro utils, we pave the way for better type safety and cleaner internal APIs.

Impact

Internal API Change: Methods in HoodieSchemaUtils and HoodieSchemaCompatibility now play a larger role in schema validation and evolution logic.
No User-Facing Change: This is a code health and refactoring PR; there are no changes to public configs or external behaviors.

Risk Level

Low

Documentation Update

none

Contributor's checklist

Read through contributor's guide
Enough context is provided in the sections above
Adequate tests were added if applicable

the-other-tim-brown · 2025-12-11T02:10:07Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/HoodieTable.java

+      HoodieSchemaField tableField = tableSchema.getField(columnName).get();

      if (tableField == null) {


Let's update this to first return an Option and then we can check if it is present instead of checking for null here.

the-other-tim-brown · 2025-12-11T02:10:46Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/HoodieTable.java

      if (writerField != null && !tableField.schema().equals(writerField.schema())) {
        // Check if this is just making the field nullable/non-nullable, which is safe from SI perspective
-        if (getNonNullTypeFromUnion(tableField.schema()).equals(getNonNullTypeFromUnion(writerField.schema()))) {
+        HoodieSchema nonNullTableField = HoodieSchemaUtils.getNonNullTypeFromUnion(tableField.schema());


Let's use the getNonNullType method on the HoodieSchema when possible

the-other-tim-brown · 2025-12-11T02:11:24Z

...ent/hudi-spark-client/src/main/java/org/apache/hudi/io/storage/HoodieSparkParquetReader.java


  @Override
  public ClosableIterator<HoodieRecord<InternalRow>> getRecordIterator(HoodieSchema schema) throws IOException {
    //TODO boundary to revisit in later pr to use HoodieSchema directly


Let's remove this TODO now

the-other-tim-brown · 2025-12-11T02:17:07Z

hudi-common/src/main/java/org/apache/hudi/common/schema/HoodieSchemaCompatibility.java

+   * @return the writer field, if any does correspond, or None.
+   */
+  public static HoodieSchemaField lookupWriterField(final HoodieSchema writerSchema, final HoodieSchemaField readerField) {
+    assert (writerSchema.getType() == HoodieSchemaType.RECORD);


Let's use the ValidationUtils here so we can return a more customized error message if the type is not RECORD

the-other-tim-brown · 2025-12-11T02:17:38Z

hudi-common/src/main/java/org/apache/hudi/common/schema/HoodieSchemaCompatibility.java

+   */
+  public static HoodieSchemaField lookupWriterField(final HoodieSchema writerSchema, final HoodieSchemaField readerField) {
+    assert (writerSchema.getType() == HoodieSchemaType.RECORD);
+    final List<HoodieSchemaField> writerFields = new ArrayList<>();


It looks like the list is expected to have 0 or 1 elements so an Option may fit this usecase better, what do you think?

Yeap make sense!

the-other-tim-brown · 2025-12-11T02:20:31Z

hudi-common/src/main/java/org/apache/hudi/common/table/PartitionPathParser.java

+      Option<HoodieSchemaField> fieldOpt = schema.getField(partitionField);
      // if the field is not present in the schema, we assume it is a string
-      Schema fieldSchema = field == null ? Schema.create(Schema.Type.STRING) : getNonNullTypeFromUnion(field.schema());
-      LogicalType logicalType = fieldSchema.getLogicalType();
+      HoodieSchema fieldSchema = fieldOpt.isEmpty() ? HoodieSchema.create(HoodieSchemaType.STRING) : HoodieSchemaUtils.getNonNullTypeFromUnion(fieldOpt.get().schema());
+      HoodieSchemaType logicalType = fieldSchema.getType();


Suggested change

Option<HoodieSchemaField> fieldOpt = schema.getField(partitionField);

// if the field is not present in the schema, we assume it is a string

Schema fieldSchema = field == null ? Schema.create(Schema.Type.STRING) : getNonNullTypeFromUnion(field.schema());

LogicalType logicalType = fieldSchema.getLogicalType();

HoodieSchema fieldSchema = fieldOpt.isEmpty() ? HoodieSchema.create(HoodieSchemaType.STRING) : HoodieSchemaUtils.getNonNullTypeFromUnion(fieldOpt.get().schema());

HoodieSchemaType logicalType = fieldSchema.getType();

Option<HoodieSchemaField> field = schema.getField(partitionField);

// if the field is not present in the schema, we assume it is a string

HoodieSchema fieldSchema = field.map(f -> f.schema().getNonNullType()).orElseGet(() -> HoodieSchema.create(HoodieSchemaType.STRING));

the-other-tim-brown · 2025-12-11T02:21:14Z

hudi-common/src/main/java/org/apache/hudi/common/table/PartitionPathParser.java

-        || logicalType instanceof LogicalTypes.TimeMicros
-        || logicalType instanceof LogicalTypes.LocalTimestampMicros
-        || logicalType instanceof LogicalTypes.LocalTimestampMillis;
+  private static boolean isTimeBasedLogicalType(HoodieSchemaType logicalType) {


Suggested change

private static boolean isTimeBasedLogicalType(HoodieSchemaType logicalType) {

private static boolean isTimeBasedType(HoodieSchemaType type) {

The logical type is an Avro concept. We have proper types for date, time, timestamp, etc now

Will modify, once your PR is merged, I'll prioritise your changes over mine for this.

the-other-tim-brown · 2025-12-11T02:24:37Z

hudi-hadoop-common/src/test/java/org/apache/hudi/common/table/TestTableSchemaResolver.java

+    assertEquals(f.schema(), HoodieSchema.createNullable(HoodieSchemaType.STRING));

    // case5: user_partition is in originSchema, but partition_path is in originSchema
-    String[] pts4 = {"user_partition", "partition_path"};


Do you think this is an error in the original test? It seems like this should be used below.

Using pts4 for the last test will cause the test to fail. I checked the git blame. This variable is there since the creation of this file. I hazard that this is WIP var that the original author forgot to remove this.

the-other-tim-brown · 2025-12-11T02:28:39Z

hudi-utilities/src/main/java/org/apache/hudi/utilities/schema/KafkaOffsetPostProcessor.java

  }

  @Override
+  public HoodieSchema processSchema(HoodieSchema schema) {


This was not overridden on purpose in case a user is extending the deprecated method.

Okay, will remove then, will keep the AvroSchemaUtils usage in the old deprecated, but will fully qualify it.

the-other-tim-brown · 2025-12-11T03:46:47Z

...main/java/org/apache/hudi/client/transaction/ConcurrentSchemaEvolutionTableSchemaGetter.java

          .or(() -> Option.of(schema))
          .get();


Nitpick: while we're updating this, let's change this to use orElseGet instead of or and get

the-other-tim-brown · 2025-12-11T03:48:14Z

...main/java/org/apache/hudi/client/transaction/ConcurrentSchemaEvolutionTableSchemaGetter.java

+  private Option<HoodieSchema> getTableCreateSchemaWithoutMetaField() {
+    return metaClient.getTableConfig().getTableCreateSchema()
+        .map(HoodieSchema::fromAvroSchema)
+        .or(Option.empty());


We shouldn't need the or in this case

the-other-tim-brown · 2025-12-11T03:50:45Z

hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/HoodieTable.java

-      AvroSchemaUtils.checkSchemaCompatible(tableSchema, writerSchema, shouldValidate, allowProjection, getDropPartitionColNames());
+
+      HoodieSchema writerSchema = HoodieSchemaUtils.createHoodieWriteSchema(config.getSchema(), false);
+      HoodieSchema tableSchema = HoodieSchema.createHoodieWriteSchema(existingTableSchema.get().toString(), false);


Instead of converting existingTableSchema to a string, let's create a method that takes in a HoodieSchema similar to the AvroSchemaUtils

It invokes org.apache.hudi.avro.HoodieAvroUtils#addMetadataFields(org.apache.avro.Schema, boolean), I don't think we need a new method, let's just call org.apache.hudi.common.schema.HoodieSchemaUtils#addMetadataFields(org.apache.hudi.common.schema.HoodieSchema).

the-other-tim-brown · 2025-12-11T03:52:12Z

...-spark-client/src/main/java/org/apache/hudi/io/storage/row/HoodieRowParquetWriteSupport.java

  private final boolean writeLegacyListFormat;
  private final ValueWriter[] rootFieldWriters;
-  private final Schema avroSchema;
+  private final HoodieSchema hoodieSchema;


nitpick: let's update hoodieSchema variable names to simply schema?

the-other-tim-brown · 2025-12-11T03:53:03Z

...-spark-client/src/main/java/org/apache/hudi/io/storage/row/HoodieRowParquetWriteSupport.java

-        return (row, ordinal) -> recordConsumer.addLong((long) timestampRebaseFunction.apply(row.getLong(ordinal)));
-      } else if (logicalType.getName().equals(LogicalTypes.timestampMillis().getName())) {
-        return (row, ordinal) -> recordConsumer.addLong(DateTimeUtils.microsToMillis((long) timestampRebaseFunction.apply(row.getLong(ordinal))));
+      if (resolvedSchema instanceof HoodieSchema.Timestamp) {


let's use the HoodieSchemaType instead of instanceof checks to determine the type of the field

the-other-tim-brown · 2025-12-11T03:54:26Z

...-spark-client/src/main/java/org/apache/hudi/io/storage/row/HoodieRowParquetWriteSupport.java

-        return (row, ordinal) -> recordConsumer.addLong(row.getLong(ordinal));
-      } else if (logicalType.getName().equals(LogicalTypes.localTimestampMillis().getName())) {
-        return (row, ordinal) -> recordConsumer.addLong(DateTimeUtils.microsToMillis(row.getLong(ordinal)));
+      if (resolvedSchema instanceof HoodieSchema.Timestamp) {


Similarly here let's use the type

the-other-tim-brown · 2025-12-11T03:55:48Z

hudi-common/src/main/java/org/apache/hudi/common/schema/HoodieSchemaCompatibility.java

+    ValidationUtils.checkArgument(writerSchema.getType() == HoodieSchemaType.RECORD, writerSchema + " is not a record");
+    Option<HoodieSchemaField> result = Option.empty();
+    final Option<HoodieSchemaField> directOpt = writerSchema.getField(readerField.name());
+    if (directOpt.isPresent()) {


Do we need a separate variable for the result? Can we just use directOpt directly?

Nope, simplified this. Was too fixated on keeping directOpt final, my bad,

the-other-tim-brown · 2025-12-11T03:57:47Z

hudi-hadoop-mr/src/test/java/org/apache/hudi/hadoop/utils/TestHoodieArrayWritableAvroUtils.java

    Object javaInput = ObjectInspectorConverters.getConverter(writableOIOld, oldObjectInspector).convert(oldWritable);
-    if (isDecimalSchema(oldSchema)) {
-      javaInput = HoodieAvroUtils.DECIMAL_CONVERSION.toFixed(getDecimalValue(javaInput, oldSchema), oldSchema, oldSchema.getLogicalType());
+    if (oldSchema instanceof HoodieSchema.Decimal) {


Let's use the schema type in this class as well

voonhous · 2025-12-12T08:21:32Z

Had to squash as i had too many commits and resolving conflicts one by one was too painful.

the-other-tim-brown · 2025-12-12T14:58:55Z

hudi-hadoop-mr/src/main/java/org/apache/hudi/hadoop/utils/HoodieArrayWritableAvroUtils.java

 import static org.apache.hudi.avro.HoodieAvroUtils.toJavaDate;
 import static org.apache.hudi.common.util.StringUtils.getUTF8Bytes;

 public class HoodieArrayWritableAvroUtils {


Should we update this class name to just be HoodieArrayWritableSchemaUtils

Yeap, cool with me.

the-other-tim-brown · 2025-12-12T15:00:54Z

hudi-hadoop-mr/src/main/java/org/apache/hudi/hadoop/utils/HoodieArrayWritableAvroUtils.java

+            HoodieSchemaField oldField = oldFieldOpt.get();
            values[i] = rewriteRecordWithNewSchema(arrayWritable.get()[oldField.pos()], oldField.schema(), newField.schema(), renameCols, fieldNames);
-          } else if (newField.defaultVal() instanceof JsonProperties.Null) {
+          } else if (newField.defaultVal().isPresent() && newField.defaultVal().get() instanceof JsonProperties.Null) {


JsonProperties needs to be HoodieJsonProperties now

Changing this to HoodieSchema.NULL_VALUE they are the same underlying value.

the-other-tim-brown · 2025-12-12T15:02:56Z

hudi-common/src/main/java/org/apache/hudi/common/schema/HoodieSchemaCompatibility.java

+   * @return true if reader schema can read data written with writer schema
+   * @throws IllegalArgumentException if schemas are null
+   */
+  public static boolean isSchemaCompatible(HoodieSchema readerSchema, HoodieSchema writerSchema,


Are there existing test cases we can migrate to TestHoodieSchemaCompatibility as part of this PR?

Nope, I'll add some.

- Fix checkstyle - Add tests - Address comments - Fix failing azure IT - Fix compilation errors after rebase - Fix failing TestHoodieFileGroupReaderOnFlink tests - Fix failing TestHoodieFileGroupReaderOnHive - Fix failing TestPartitionPathParser tests - Address comments - Fix Java17 compilation error - Fix checkstyle - Fix direct #get() usages in HoodieRowParquetWRiteSupport - Fix removal - Remove AvroSchemaUtils usage from TestParquetUtils - Remove AvroSchemaUtils usage from HoodieSparkParquetReader - Remove AvroSchemaUtils usage from HoodieTable - Remove AvroSchemaUtils usage from HoodieTestDataGenerator - Fix tests from missing namespace and doc - Remove Avro.Schema and AvroSchemaUtils usage from HoodieArrayWritableAvroUtils - Adapt KafkaOffsetPostProcessor - Ignore AvroSchemaUtils#getAvroRecordQualifiedName usages - Remove AvroSchemaUtils from TestHoodieCommitMetadata - Remove AvroSchemaUtils from HoodieRowParquetWriteSupport - Remove AvroSchemaUtils from HoodieRealtimeRecordReaderUtils - Remove AvroSchemaUtils from TestMergeHandle - Ignore ParquetRowIndexBasedSchemaHandler - Add ignore flag in FileGroupReaderSchemaHandler - Add ignore flag in OrderingValueEngineTypeConverter - Remove AvroSchemaUtils usage from ConcurrentSchemaEvolutionTableSchemaGetter and TableSchemaResolver - Remove AvroSchemaUtils usages from PartitionPathParser and TestPartitionPathParser - Remove AvroSchemaUtils usages from TestHoodieSchemaCompatibility - Remove AvroSchemaUtils usages from TestSparkSortAndSizeClustering - Remove AvroSchemaUtils usages from TestHoodieAvroReaderContext - Ignore AvroSchemaRepair and TestAvroSchemaRepair - Remove AvroSchemaUtils usage from FlinkRowDataReaderContext - Ignore SchemaBackwardsCompatibilityException - Ignore HiveAvroSerializer and HiveTypeUtils + fully qualify AvroSchemaUtils usages - Ignore HoodieSchemaUtils - Ignore MissingSchemaFieldException - Remove AvroSchemaUtils from HoodieMergeHelper - Ignore classes: - HoodieAvroReaderContext - AvroRecordContext - HoodieSchemaCompatibility - Fully qualify AvroSchemaUtils call in HoodieAvroUtils - Remove flags from *AvroSchemaUtils - Add more references to AvroSchemaUtils missed out on first scan - Remove AvroSchemaUtils and Avro.Schema usage in HoodieTable and HoodieWriteHandle - Remove AvroSchemaUtils and Avro.Schema usage in TestTableSchemaEvolution - Find all AvroSchemaUtils usages and prefix them with comment /*~~>*/

the-other-tim-brown · 2025-12-15T15:37:40Z

...-spark-client/src/main/java/org/apache/hudi/io/storage/row/HoodieRowParquetWriteSupport.java

      } else {
-        throw new UnsupportedOperationException("Unsupported Avro logical type for TimestampType: " + logicalType);
+        // Default to micros precision when no timestamp schema is available
+        return (row, ordinal) -> recordConsumer.addLong((long) timestampRebaseFunction.apply(row.getLong(ordinal)));


Previously it looks like this threw an UnsupportedOperationException, should we keep that?

~~Sure, it's unlikely that we'll step into this clause, so, Exception might be safer.~~

Sure, it's I believe it's unlikely that we'll step into this clause, so, Exception might be safer.

I was trying to capture the case of logicalType == null. I am not sure if HoodieSchema will resolve an Avro schema to a case where logicalType == null.

Comment addressed.

hudi-bot · 2025-12-15T19:08:59Z

CI report:

0354017 UNKNOWN
6e31559 UNKNOWN
a7649ab UNKNOWN
f6a9e8a UNKNOWN
2ef24a7 UNKNOWN
219eb35 UNKNOWN
a7c76c3 UNKNOWN
fb8531b UNKNOWN
bcd1764 UNKNOWN
3be646d Azure: SUCCESS

Bot commands

@hudi-bot supports the following commands:

@hudi-bot run azure re-run the last Azure build

voonhous · 2025-12-16T02:32:35Z

CI + Azure CI passed.

Squashing and merging this in.

github-actions bot added size:M PR with lines of changes in (100, 300] size:L PR with lines of changes in (300, 1000] and removed size:M PR with lines of changes in (100, 300] labels Dec 9, 2025

voonhous marked this pull request as draft December 10, 2025 04:21

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch 4 times, most recently from 228d0dc to ac69a39 Compare December 10, 2025 05:39

github-actions bot added size:M PR with lines of changes in (100, 300] and removed size:L PR with lines of changes in (300, 1000] labels Dec 10, 2025

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch 2 times, most recently from 1531814 to 72aa418 Compare December 10, 2025 06:29

github-actions bot added size:L PR with lines of changes in (300, 1000] and removed size:M PR with lines of changes in (100, 300] labels Dec 10, 2025

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch 8 times, most recently from f9ba546 to 89cd44a Compare December 10, 2025 11:06

github-actions bot added size:XL PR with lines of changes > 1000 and removed size:L PR with lines of changes in (300, 1000] labels Dec 10, 2025

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch from 00b71d6 to a1695a2 Compare December 10, 2025 16:42

voonhous marked this pull request as ready for review December 10, 2025 16:47

voonhous requested a review from the-other-tim-brown December 10, 2025 17:03

apache deleted a comment from hudi-bot Dec 10, 2025

the-other-tim-brown reviewed Dec 11, 2025

View reviewed changes

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch from 8e94f63 to 0354017 Compare December 11, 2025 02:56

the-other-tim-brown reviewed Dec 11, 2025

View reviewed changes

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch 6 times, most recently from e88014e to 219eb35 Compare December 12, 2025 08:20

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch from 219eb35 to 264c04c Compare December 12, 2025 08:27

voonhous changed the title ~~feat(schema): phase 17 - Remove AvroSchemaUtils usage~~ feat(schema): phase 17 - Remove AvroSchemaUtils usage (part 1) Dec 12, 2025

This was referenced Dec 12, 2025

feat(schema): phase 17 - Remove AvroSchemaUtils usage (part 2) #17581

Merged

Phase 17: AvroSchemaUtils Method Removal #14282

Closed

the-other-tim-brown reviewed Dec 12, 2025

View reviewed changes

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch 4 times, most recently from fb8531b to 4567f05 Compare December 13, 2025 09:27

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch from 4567f05 to 2654cac Compare December 14, 2025 11:21

voonhous requested a review from the-other-tim-brown December 15, 2025 04:16

the-other-tim-brown reviewed Dec 15, 2025

View reviewed changes

Address comments

3be646d

voonhous force-pushed the phase-17-AvroSchemaUtils-removal branch from bcd1764 to 3be646d Compare December 15, 2025 16:29

the-other-tim-brown approved these changes Dec 15, 2025

View reviewed changes

voonhous merged commit bf70d4c into apache:master Dec 16, 2025
135 of 137 checks passed

voonhous deleted the phase-17-AvroSchemaUtils-removal branch December 16, 2025 02:33

voonhous linked an issue Jan 3, 2026 that may be closed by this pull request

Phase 17: AvroSchemaUtils Method Removal #14282

Closed

		HoodieSchemaField tableField = tableSchema.getField(columnName).get();

		if (tableField == null) {

	private static boolean isTimeBasedLogicalType(HoodieSchemaType logicalType) {
	private static boolean isTimeBasedType(HoodieSchemaType type) {

feat(schema): phase 17 - Remove AvroSchemaUtils usage (part 1) #17535

feat(schema): phase 17 - Remove AvroSchemaUtils usage (part 1) #17535

Uh oh!

Conversation

voonhous commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Describe the issue this Pull Request addresses

Summary and Changelog

Impact

Risk Level

Documentation Update

Contributor's checklist

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

voonhous Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

voonhous commented Dec 9, 2025 •

edited

Loading

voonhous Dec 11, 2025 •

edited

Loading

voonhous Dec 15, 2025 •

edited

Loading

voonhous Dec 15, 2025 •

edited

Loading