Add arrow-avro Reader support for Dense Union and Union resolution (Part 2) #8349

jecsand838 · 2025-09-15T06:16:17Z

Which issue does this PR close?

This work continues arrow-avro schema resolution support and aligns behavior with the Avro spec.

Related to: Add Avro Support #4886 (“Add Avro Support”): ongoing work to round out the reader/decoder, including schema resolution and type promotion.
Follow-ups/Context: Add arrow-avro Reader support for Dense Union and Union resolution (Part 1) #8348 (Add arrow-avro Reader support for Dense Union and Union resolution (Part 1)), Add projection with default values support to RecordDecoder #8293 (Add projection with default values support to RecordDecoder), Add schema resolution and type promotion support to arrow-avro Decoder #8124 (schema resolution & type promotion for the decoder), Added arrow-avro enum mapping support for schema resolution #8223 (enum mapping for schema resolution). These previous efforts established the foundations that this PR extends to Union types and Union resolution.

Rationale for this change

arrow-avro lacked end‑to‑end support for Avro unions and Arrow Union schemas. Many Avro datasets rely on unions (i.e.., ["null","string"], tagged unions of different records), and without schema‐level resolution and JSON encoding the crate could not interoperate cleanly. This PR complete the initial Decoder support for Union types and Union resolution.

What changes are included in this PR?

Decoder support for Dense Union decoding and Union resolution.

Are these changes tested?

Yes,
New detailed end to end integration tests have been added to reader/mod.rs and unit tests covering the new Union and Union resolution functionality are included in the reader/record.rs file.

Are there any user-facing changes?

N/A

nathaniel-d-ef

This looks really solid to me, great work 👍

jecsand838 · 2025-09-18T18:30:35Z

@alamb @scovich Would either of you have time to review this PR? Half of the PR is test code, so the actual production code diff is about ~900 lines. I also have ideas on improving this further and plan to refine it in follow-up PRs.

This was an interesting one to tackle and I found it challenging to do so in a clean manner.

Finally this is a pretty important PR, as it's the last major PR the Reader should need before being functionally ready for public release. As such, I made sure that the code was throughly tested end to end.

scovich

I'm pretty far out of my expertise on this PR, but hopefully the comments are still useful.

arrow-avro/src/reader/record.rs

scovich · 2025-09-19T10:53:05Z

arrow-avro/src/reader/record.rs

+        reader_type_codes: Arc<[i8]>,
+    },
+    ToSingle {
+        target: Box<Decoder>,


Decoder seems to be a concrete type, so why boxed? Is there somehow infinite type recursion?

That's correct, there's the possibility of infinite type recursion with Decoder. I was planning to come back and attempt to remove the need for Box, but that would also impact Array, Map, and Nullable.

scovich · 2025-09-19T10:55:23Z

arrow-avro/src/reader/record.rs

+}
+
+impl UnionResolutionBuilder {
+    #[inline]


It seems highly unlikely that building union resolvers would be on the critical path of any workload that involves any actual data? Is #[inline] really needed on these methods?

That's a good callout, I'll remove those.

scovich · 2025-09-19T10:56:17Z

arrow-avro/src/reader/record.rs

+    fn with_resolved_union(mut self, resolved_union: &ResolvedUnion) -> Self {
+        self.resolved = Some(resolved_union.clone());


I believe it's recommended to take an owned arg, if owned is needed. Otherwise, a caller who could relinquish ownership of a value cannot do so, and we end up needlessly cloning.

... but it looks like all callers of this (private) method only have a reference, so maybe it's fine to leave as-is?

Actually you're right. We should remove the clone from here and clean this up.

arrow-avro/src/reader/record.rs

scovich · 2025-09-19T11:58:10Z

arrow-avro/src/reader/record.rs

+                UnionResolvedKind::FromSingle {
+                    target_reader_index,
+                    ..
+                } => {
+                    let type_id = fields


Seems like a lot of redundancy between Both and FromSingle cases?
I think the former just hardwires target_reader_index=0?

@scovich There's definitely some redundancy here. I tried to abstract it as much as I could without a refactor. I'm leaving these branches separate because the spec is clear there's two different types of resolution as play and I'm unsure how Sparse Unions will fit in here. I planned to follow-up on this.

scovich · 2025-09-19T11:59:48Z

arrow-avro/src/reader/record.rs

+                let type_id = fields
+                    .iter()
+                    .nth(idx)
+                    .map(|(type_id, _)| type_id)
+                    .unwrap_or_else(|| i8::try_from(idx).unwrap_or(0));
+                type_ids.push(type_id);
+                offsets.push(encoding_counts[idx]);
+                encodings[idx].decode(buf)?;
+                encoding_counts[idx] += 1;


More redundancy with the previous block of code?

@scovich So I ended up realizing that we'd need some sort of dedicated UnionDecoder implementation to fully abstract this cleanly. I was wanting to follow-up on that as part of the same future PR. It would be a pretty large charge and I want to make sure to develop it in a way that covers sparse Union types as well.

arrow-avro/src/reader/record.rs

scovich · 2025-09-19T12:05:54Z

arrow-avro/src/reader/record.rs

+                    "Promotion String->Bytes target mismatch".into(),
+                )),
+            },
+            Promotion::BytesToString => match self {


This one isn't the same as the others... it's technically a narrowing cast which could fail if the input bytes are not valid utf-8. At least the int -> float conversions are converting casts (= infallible).

Does the spec require this? And if so, should we validate the data here?

Yeah, the spec requires BytesToString promotions.

I'll clean this up a bit more though to your point.

No check that the input bytes are valid utf-8?

I think the call std::str::from_utf8(data) below validates that the input is valid utf8

scovich · 2025-09-19T12:06:56Z

arrow-avro/src/reader/record.rs

+            Promotion::LongToFloat => match self {
+                Self::Float32(v) => {
+                    v.push(buf.get_long()? as f32);
+                    Ok(())
+                }
+                _ => Err(ArrowError::ParseError(
+                    "Promotion Long->Float target mismatch".into(),
+                )),
+            },
+            Promotion::LongToDouble => match self {


Technically these are narrowing/converting casts because f32 and f64 respectively have only 24 and 53 bits of precision (same problem casting i32 to f32).

Does the spec require treating this as a "promotion" even tho it's lossy?

Yes it does, per the spec

long is promotable to float or double

100% get what you're saying though.

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

jecsand838 · 2025-09-21T06:38:49Z

I'm pretty far out of my expertise on this PR, but hopefully the comments are still useful.

@scovich Thank you so much for the review. Your comments were very useful and most of them should now be addressed in my latest commit.

I'm wanting to follow-up on handling some of the redundancy you called out in your review. While I did clean up and abstracted what made sense, I think a full abstraction is part of a larger effort that needs to consider sparse unions as well.

Let me know what you think whenever you get a chance!

scovich

Mostly nits. Just two questions before merge:

#8349 (comment) - Should bytes -> string promotion validate that the bytes contain only valid utf-8?
#8349 (comment) - Can UnionDecoder use a three-valued enum instead of a pair of booleans to capture the three valid stats? Or is there a legit reason somebody needs us to support the false/false case as passthrough?

(NOTE: I'm not an avro spec expert, so hopefully I'm not the only stamp on this PR)

arrow-avro/src/reader/record.rs

scovich · 2025-09-22T22:19:25Z

arrow-avro/src/reader/record.rs

+                    "Sparse Arrow unions are not yet supported".to_string(),
+                ));
            }
+            (Codec::Uuid, _) => Self::Uuid(Vec::with_capacity(DEFAULT_CAPACITY)),


Uuid didn't change? Can/should we leave it in its original position to reduce diff churn?

scovich · 2025-09-22T22:24:29Z

arrow-avro/src/reader/record.rs


 impl Decoder {
    fn try_new(data_type: &AvroDataType) -> Result<Self, ArrowError> {
        // Extract just the Promotion (if any) to simplify pattern matching


This comment might be a bit stale?

Or maybe just needs to move down to try_new_internal that it seems to have been split apart from?

scovich · 2025-09-22T22:27:31Z

arrow-avro/src/reader/record.rs

+            Self::Record(_, e, _) => {
+                for encoding in e.iter_mut() {
+                    encoding.append_null();
+                }
+            }


Why changed, out of curiosity? Doesn't seem related to this PR?
Did clippy flag it for some reason?

The change is related to me modifying the signature for append_null(&mut self) -> Result<(), ArrowError> to help bubble up errors from the new Union branch.

scovich · 2025-09-22T22:29:28Z

arrow-avro/src/reader/record.rs

+                    "Promotion String->Bytes target mismatch".into(),
+                )),
+            },
+            Promotion::BytesToString => match self {


No check that the input bytes are valid utf-8?

scovich · 2025-09-22T22:44:35Z

arrow-avro/src/reader/record.rs

+                "UnionDecoder::try_new cannot build writer-union to single; use UnionDecoderBuilder with a target"
+                    .to_string(),
+            )),
+            (false, false) => Ok(UnionReadPlan::Passthrough),


Is there a way to systematically eliminate this false/false case?
Does any legitimate (transitive) call site actually need it?
Or can we replace the pair of booleans with a three-variant enum?

scovich · 2025-09-22T22:51:53Z

arrow-avro/src/reader/record.rs

            Self::Array(field, offsets, values) => {
                let values = values.flush(None)?;


aside: picking on the docs a bit --

the implementation expects them to be positive

Technically, zero is not mathematically positive... it's the only value that is both non-negative and non-positive.

Perhaps rust officially has some other definition, but Google search AI overview doesn't seem to think so:

arrow-avro/src/reader/record.rs

scovich · 2025-09-22T22:58:36Z

arrow-avro/src/reader/record.rs

+        let type_ids_buf = flush_values(&mut self.type_ids).into_iter().collect();
+        let offsets_buf = flush_values(&mut self.offsets).into_iter().collect();


nit: Do these stay one-liners if folded in to their respective single use sites (below)?
Or does that hurt readability?

arrow-avro/src/reader/record.rs

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

jecsand838 · 2025-09-23T00:50:27Z

@scovich

No check that the input bytes are valid utf-8?

I wanted to avoid validating per‑value in the hot decode path. Right now malformed writer data will fail at flush time when we build the Arrow array. I could probably do a fail‑fast check at decode time via a feature flag as part of a follow-up PR though.

aside: picking on the docs a bit --

the implementation expects them to be positive

Technically, zero is not mathematically positive... it's the only value that is both non-negative and non-positive.

Perhaps rust officially has some other definition, but Google search AI overview doesn't seem to think so:

Super valid call out. I'd imagine rust follows the mathematical definition. Maybe worth cleaning up at some point.

jecsand838 · 2025-09-23T02:21:17Z

@scovich Thanks for the solid follow-up! I just pushed a commit that addresses your comments.

Also to answer those questions you had:

#8349 (comment) - Should bytes -> string promotion validate that the bytes contain only valid utf-8?

I thought about it more and realized adding the utf-8 check now is a good idea. I'm planning a fast follow-up to refine the promotion logic and can determine whether a feature flag to toggle that check off in the hot path is worth it then. Just pushed that change up.

#8349 (comment) - Can UnionDecoder use a three-valued enum instead of a pair of booleans to capture the three valid stats? Or is there a legit reason somebody needs us to support the false/false case as passthrough?

I looked at the code again and didn't see a legitimate case where UnionDecoder should be constructed if neither side is a union, i.e. (false, false) => Passthrough. My latest push cleaned that up.

CC: @alamb @mbrobbel

scovich · 2025-09-23T02:32:26Z

No check that the input bytes are valid utf-8?

I wanted to avoid validating per‑value in the hot decode path. Right now malformed writer data will fail at flush time when we build the Arrow array. I could probably do a fail‑fast check at decode time via a feature flag as part of a follow-up PR though.

Fair! Arrow array build failure seems soon enough to detect what is hopefully a super uncommon case?

jecsand838 · 2025-09-23T02:55:27Z

No check that the input bytes are valid utf-8?

I wanted to avoid validating per‑value in the hot decode path. Right now malformed writer data will fail at flush time when we build the Arrow array. I could probably do a fail‑fast check at decode time via a feature flag as part of a follow-up PR though.

Fair! Arrow array build failure seems soon enough to detect what is hopefully a super uncommon case?

It's pretty uncommon. I've only seen it with malformed data anecdotally. However having an optional fail fast path in these promotions is probably a good idea though.

alamb · 2025-09-23T18:24:09Z

CI failure unrelated to this PR

Fix clippy #8426

alamb

Thank you @jecsand838 and @scovich

I had a few suggestions, but the most important one I would really like to see is the "end to end" test that reads the data from union_fields.avro and verifies the resulting UnionArray directly

arrow-avro/src/reader/mod.rs

alamb · 2025-09-23T18:52:37Z

arrow-avro/src/reader/mod.rs

+            assert_union_equivalent("record_with_union_field.u", u_b, u_r);
+        }
+    }
+


One test I think Would be super valuable would be a more "end to end" test showing the output of this logic as Arrow arrays.

Perhaps a test like

read the file in

programatically create the expected UnionArray

assert_eq they are the same

Just pushed up a full e2e test that compares Arrow arrays as well. This was a good call!

alamb · 2025-09-23T18:54:18Z

arrow-avro/src/reader/record.rs

+                    "Promotion String->Bytes target mismatch".into(),
+                )),
+            },
+            Promotion::BytesToString => match self {


I think the call std::str::from_utf8(data) below validates that the input is valid utf8

alamb · 2025-09-23T18:55:43Z

arrow-avro/src/reader/record.rs

+}
+
+#[derive(Debug)]
+struct DispatchLookupTable {


it would help me read this code if the indexing were explicitly described

Specifically, what does the index in to_reader and promotion represent? I think it is the output column index and the value is the input column index?

It would also be nice to document that some of the to_reader entries may be -1 and what that means

Added detailed comments for the DispatchLookupTable.

arrow-avro/src/reader/record.rs

alamb · 2025-09-23T18:59:43Z

arrow-avro/src/reader/record.rs

+                "Negative union branch index {tag}"
+            )));
+        }
+        Ok(tag as usize)


I am not sure it will matter, but I think long (64 bit signed) may not fit into a usize on 32-bit platforms

Another way to do this test that would catch it is something like

let tag: usize = buf.get_long().try_into() .map_err(|_| { ArrowError::ParseError(format!(ArrowError::ParseError(format! "Negative union branch index {tag}" ))})?;

I think union type tags are restricted to 0..=127?

I am not sure it will matter, but I think long (64 bit signed) may not fit into a usize on 32-bit platforms

Another way to do this test that would catch it is something like

Great catch! ty for that. I'll switch to a fallible conversion, improve the error messages, and clean-up. This will cover both negative indices and (on 32‑bit) non‑negative indices that don’t fit in usize. The same fix will be applied in the skipper path.

I can refine this further in a follow-up PR as well if that's alright with you.

I think union type tags are restricted to 0..=127?

That 0..=127 bound applies to Arrow union type_ids (int8), not to Avro tags. In Avro, the tag is the zero‑based union branch index (encoded as an int in 1.11.1), so it’s only constrained by the number of union branches (it must be non‑negative and < branch count).

There is an issue here that could fail a valid Avro files.

In the (incredibly unlikely and never seen it before personally) scenario we get a reader asking us to materialize an Arrow union with >127 branches we'll have an error. That's more of a Arrow format limitation on the UnionFields as I understand it. Something to follow-up on at some point imo and I can update the docs in a fast follow PR as well.

Oh... what's the largest legal union branch value that avro supports?

I don't think we need to support super lage unions, I was just trying to make sure we had some reasonable error message if we don't support that case

Oh... what's the largest legal union branch value that avro supports?

In 1.11.x+ it's 32‑bit signed int, so 2,147,483,647. Older versions of the spec just defined it as long if I remember correctly. In practice, I've never seen unions get anywhere close to this size.

Just pushed up some better checks in the cold path and better error messages.

Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>

jecsand838 · 2025-09-23T21:32:46Z

Thank you @jecsand838 and @scovich

I had a few suggestions, but the most important one I would really like to see is the "end to end" test that reads the data from union_fields.avro and verifies the resulting UnionArray directly

@alamb Thank you for the solid feedback and suggestions. I pushed up changes that include the end to end test and address your comments. Let me know what you think!

I think the call std::str::from_utf8(data) below validates that the input is valid utf8

That's correct. I just removed that again and will come back to improving the validation as a fast follow PR. For now invalid UTF8 will get caught in the flush.

alamb · 2025-09-24T10:34:59Z

Thanks @jecsand838, @nathaniel-d-ef and @scovich -- I am really excited to see how the arrow-avro crate is shaping up

github-actions bot added arrow Changes to the arrow crate arrow-avro arrow-avro crate labels Sep 15, 2025

jecsand838 force-pushed the avro-reader-union-support-decoder branch 3 times, most recently from f6f21ad to e606f43 Compare September 15, 2025 06:50

Added decoder support for Union types and Union resolution.

976730a

jecsand838 force-pushed the avro-reader-union-support-decoder branch from e606f43 to 976730a Compare September 15, 2025 16:32

jecsand838 mentioned this pull request Sep 15, 2025

Use arrow-avro for performance and improved type support apache/datafusion#14097

Open

jecsand838 force-pushed the avro-reader-union-support-decoder branch from afc9006 to 1a73c4b Compare September 16, 2025 08:15

Merge branch 'main' into avro-reader-union-support-decoder

1c1e58c

jecsand838 force-pushed the avro-reader-union-support-decoder branch from 1a73c4b to 1c1e58c Compare September 17, 2025 16:05

jecsand838 added 2 commits September 17, 2025 12:51

Merge branch 'main' into avro-reader-union-support-decoder

eb63eb3

Merge branch 'main' into avro-reader-union-support-decoder

b0e0ee7

jecsand838 mentioned this pull request Sep 18, 2025

Add arrow-avro Reader support for Dense Union and Union resolution (Part 1) #8348

Merged

Merge branch 'main' into avro-reader-union-support-decoder

0d81b32

jecsand838 marked this pull request as ready for review September 18, 2025 14:43

nathaniel-d-ef approved these changes Sep 18, 2025

View reviewed changes

scovich reviewed Sep 19, 2025

View reviewed changes

jecsand838 and others added 8 commits September 20, 2025 16:39

Update arrow-avro/src/reader/record.rs

e08322b

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Merge branch 'main' into avro-reader-union-support-decoder

ca950ca

Update arrow-avro/src/reader/record.rs

1739751

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Update arrow-avro/src/reader/record.rs

6024029

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Update arrow-avro/src/reader/record.rs

fdeb875

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Update arrow-avro/src/reader/record.rs

79d113c

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Update arrow-avro/src/reader/record.rs

e793445

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Update arrow-avro/src/reader/record.rs

d636451

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

jecsand838 force-pushed the avro-reader-union-support-decoder branch from 9936c89 to d636451 Compare September 20, 2025 23:35

Address PR Comments

58890ae

scovich approved these changes Sep 22, 2025

View reviewed changes

jecsand838 and others added 3 commits September 22, 2025 18:56

Update arrow-avro/src/reader/record.rs

f212a31

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Update arrow-avro/src/reader/record.rs

ebc5a1c

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

Update arrow-avro/src/reader/record.rs

761adba

Co-authored-by: Ryan Johnson <scovich@users.noreply.github.com>

jecsand838 force-pushed the avro-reader-union-support-decoder branch from 974ea94 to 761adba Compare September 23, 2025 00:07

jecsand838 force-pushed the avro-reader-union-support-decoder branch from fe2e63e to c555bee Compare September 23, 2025 02:13

Address PR Comments

20d946f

jecsand838 force-pushed the avro-reader-union-support-decoder branch from c555bee to 20d946f Compare September 23, 2025 05:08

scovich mentioned this pull request Sep 23, 2025

Fix UnionArray references to "positive" values #8418

Closed

jecsand838 added 2 commits September 23, 2025 12:55

Merge branch 'main' into avro-reader-union-support-decoder

df78fbc

Merge branch 'main' into avro-reader-union-support-decoder

ba8c751

Merge branch 'main' into avro-reader-union-support-decoder

2990e7f

alamb approved these changes Sep 23, 2025

View reviewed changes

jecsand838 and others added 2 commits September 23, 2025 14:02

Update arrow-avro/src/reader/record.rs

99971eb

Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>

Update arrow-avro/src/reader/mod.rs

26e8e96

Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>

jecsand838 force-pushed the avro-reader-union-support-decoder branch from c1d9dfb to 26e8e96 Compare September 23, 2025 19:31

jecsand838 force-pushed the avro-reader-union-support-decoder branch from 78181ee to 9adae00 Compare September 23, 2025 22:22

Address PR Comments

f3c97a0

jecsand838 force-pushed the avro-reader-union-support-decoder branch from 9adae00 to f3c97a0 Compare September 23, 2025 23:43

Merge branch 'main' into avro-reader-union-support-decoder

ef5f73d

alamb merged commit f7ea0aa into apache:main Sep 24, 2025
23 checks passed

jecsand838 deleted the avro-reader-union-support-decoder branch September 24, 2025 15:23

jecsand838 mentioned this pull request Oct 26, 2025

Add Avro IO to arro3-io using arrow-avro kylebarron/arro3#430

Open

		fn with_resolved_union(mut self, resolved_union: &ResolvedUnion) -> Self {
		self.resolved = Some(resolved_union.clone());

		Self::Array(field, offsets, values) => {
		let values = values.flush(None)?;

		let type_ids_buf = flush_values(&mut self.type_ids).into_iter().collect();
		let offsets_buf = flush_values(&mut self.offsets).into_iter().collect();

Add arrow-avro Reader support for Dense Union and Union resolution (Part 2) #8349

Add arrow-avro Reader support for Dense Union and Union resolution (Part 2) #8349

Uh oh!

Conversation

jecsand838 commented Sep 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

nathaniel-d-ef left a comment

Choose a reason for hiding this comment

Uh oh!

jecsand838 commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

scovich left a comment

Choose a reason for hiding this comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jecsand838 Sep 20, 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!

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!

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!

jecsand838 Sep 20, 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!

jecsand838 commented Sep 21, 2025

Uh oh!

scovich left a comment • 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!

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!

jecsand838 Sep 22, 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

jecsand838 commented Sep 15, 2025 •

edited

Loading

jecsand838 commented Sep 18, 2025 •

edited

Loading

jecsand838 Sep 20, 2025 •

edited

Loading

jecsand838 Sep 20, 2025 •

edited

Loading

scovich left a comment •

edited

Loading

jecsand838 Sep 22, 2025 •

edited

Loading

jecsand838 commented Sep 23, 2025 •

edited

Loading

jecsand838 commented Sep 23, 2025 •

edited

Loading