[Variant] Speedup validation #7878

friendlymatthew · 2025-07-07T15:55:56Z

Rationale for this change

This PR contains algorithmic modifications to the validation logic and the associated benchmarks, specifically targeting complex object and list validation.

Previously, the approach involved iterating over each element and repeatedly fetching the same slice of the backing buffer, then slicing into that buffer again for each individual element. This led to redundant buffer access.

This validation approach is done in multiple passes that take advantage of the variant's memory layout. For example, dictionary field names are stored contiguously; instead of checking whether a field name is UTF8-encoded separately, we now validate the entire field name buffer in a single pass.

The benchmark cases were adapted from test_json_to_variant_object_very_large, test_json_to_variant_object_complex, and test_json_to_variant_array_nested_large test cases.

Compared to #7871, we observe a significant improvement in performance:

@scovich @alamb

friendlymatthew · 2025-07-07T16:03:44Z

Note: this is still a POC. There's some code movement to do, but I figured it would be best to leave the diff like this to make it more readable.

But the core concept is fully fleshed out.

alamb · 2025-07-07T18:12:26Z

BTW I ran the test from this ticket locally before this PR

[Variant] test_json_to_variant_object_very_large takes over 20s #7872

Previously

        PASS [  21.886s] parquet-variant::test_json_to_variant test_json_to_variant_object_very_large

Before this PR, after [Variant] Remove superflous validate call and rename methods #7871

        PASS [  15.711s] parquet-variant::test_json_to_variant test_json_to_variant_object_very_large

With this PR

        PASS [   6.570s] parquet-variant::test_json_to_variant test_json_to_variant_object_very_large

Only 6.5 seconds 🤗 -- nice work

scovich

Very interesting ideas. Made a partial pass with some ideas for improved control flow.

parquet-variant/src/variant/list.rs

scovich · 2025-07-07T19:36:37Z

parquet-variant/src/variant/list.rs

Is this faster and/or simpler than try_into from slice to array?

parquet-variant/src/variant/list.rs

scovich · 2025-07-07T19:48:49Z

parquet-variant/src/variant/list.rs

Why not Iterator::is_sorted_by?

let offsets_monotonically_increasing = offset_chunks .map(...) .is_sorted_by(...);

(again below)

Update: The code below uses the materialized offsets.

But for large objects, wouldn't it be cheaper (and simpler) to combine the checks instead of materializing the offset array? Most likely inside a helper method so the code can leverage ?:

let mut offsets = offset_chunks.map(|chunk| match chunk { ... }); let Some(mut prev_offset) = offset_chunks.next().transpose()? else { return Ok(()); }; for offset in offsets { let offset = offset?; if prev_offset >= offset { return Err(... not monotonic ...); } let value_bytes = slice_from_slice(value_buffer, prev_offset..offset)?; prev_offset = offset; let _ = Variant::try_new_with_metadata(self.metadata, value_bytes)?; }; Ok(()) }

scovich · 2025-07-07T19:49:25Z

parquet-variant/src/variant/metadata.rs

As above, no need to materialize the iterator if we combine the checks into a single loop?
(but also see comment below)

parquet-variant/src/variant/metadata.rs

scovich · 2025-07-07T20:32:14Z

parquet-variant/src/variant/object.rs

As above, I expect it will be straightforward to avoid materializing these iterators
(again below)

I agree -- it seems unecessary to allocate and copy all the values into a Vec here

Hm happy to change, but I think in this case the extra allocation isn’t hurting perf very much and it makes the code a lot simpler to reason about because we can split up the following checks better.

I could inline calls to map_bytes_to_offsets everywhere we loop over field_ids, but that doesn’t seem much better than doing a single allocation

I could inline calls to map_bytes_to_offsets everywhere we loop over field_ids, but that doesn’t seem much better than doing a single allocation

I only see one pass over field_ids? Two possible paths, but each is single-pass?
(the not-sorted-metadata case makes a second pass, but I'm pretty sure it's redundant and will never find a failure -- see other comment)

I think in this case the extra allocation isn’t hurting perf very much

Seems like something we could (should) quantify? For a not-small dictionary I would expect materialization cost to be quite noticeable. Anything big enough to fall out L1 cache would likely see a significant slowdown due to a wave of cache misses on every pass. And that includes not just the offset vec itself (easy enough to prefetch), but also the bytes of the strings and values we examine.

and it makes the code a lot simpler to reason about

I don't think that's necessarily true for the metadata and list cases above (see other comments).

For this case, it would look something like:

let field_ids = map_bytes_to_offsets(field_id_buffer, self.header.field_id_size); if let Some(mut field_id) = field_ids.next() { if self.metadata.is_sorted() { // Since the metadata dictionary has unique and sorted field names... for next_field_id in field_ids { if next_field_id <= field_id { return Err(... field names not sorted ...); } field_id = next_field_id; } } else { // The metadata dictionary can't guarantee uniqueness... ... very similar to the metadata sortedness check: scan + validate_fallible_iterator ... ... probably could even factor out a helper function that both sites can call ... } if field_id >= self.metadata.dictionary_size() { return Err(... field id is not valid ...); } }

friendlymatthew · 2025-07-09T13:53:19Z

Hi @viirya, I would appreciate your thoughts on this PR as well

alamb

Thanks @friendlymatthew -- this is making progress

I am not quite sure about the benchmarks

Also, have you had a chance to incorporate @scovich 's comment in https://github.com/apache/arrow-rs/pull/7878/files#r2190963902 ?

alamb · 2025-07-09T22:03:27Z

parquet-variant-json/benches/variant_validation.rs

this comment seems incorrect

Oof, that is what I get from lifting this code from test cases

alamb · 2025-07-09T22:03:48Z

parquet-variant-json/benches/variant_validation.rs

I ran these benchmarks locally

cargo bench --bench variant_validation

Here is some output:

Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 33.9s, or reduce sample count to 10. Benchmarking bench_validate_large_object: Collecting 100 samples in estimated 33.859 s (100 iterations)

alamb · 2025-07-09T22:04:21Z

parquet-variant-json/benches/variant_validation.rs

I think a non trivial amount of the time being measured by this benchmark is the creation of the JSON string...

See comment

Can we move the generation of large object out of benchmark? Only benchmarking validation?

Yeah, I think that would be useful. I did some profiling at more than half the time of this benchmark is spent parsing JSON

Arg -- that is embarassing. I will push up a fix soon

alamb · 2025-07-09T22:09:17Z

parquet-variant-json/benches/variant_validation.rs

I found these benchmarks somewhat confusing -- they are mostly testing json --> Variant conversion I think.

While those are useful benchmarks, they probably shouldn't be called variant_validation

SO I suggest you split this benchmark up into two:

parquet-variant/benches/variant_validation -- creates the metadata and value progrmatically with VariantBuilder once and then benchmarks callingVariant::try_new on that (precreated) metadata/value

parquet-variant-json/benches/variant_json.rs -- creates a json string once and then benchmarks how fast calling json_to_variant is

I found these benchmarks somewhat confusing -- they are mostly testing json --> Variant conversion I think.

While those are useful benchmarks, they probably shouldn't be called variant_validation

Hi, the following benchmarks use iter_batched which doesn't include the startup time (in this case, building up the variant). The benchmark runs should only involve the validation code.

Reading this issue, it seems like iter_batched_ref is a better function to use.

As for the json_to_variant, I could've built up the variant manually via the builder, but found the json example quite convenient. Since we moved json_to_variant to a separate crate, I had no choice but to move the validation benchmarks here.

But I agree, we should move this back to parquet-variant. It is a bit unfortunate, but we can manually build up the objects.

alamb · 2025-07-09T22:10:55Z

parquet-variant/src/variant/metadata.rs

I wonder how much improvement the new crate adds ?

One thing I thought was that if we create a Variant from JSON we already know all the values were utf8, so it makes sense to skip validating it again befor read

What is the difference between the currently used str::from_utf8 and this simdutf8::basic::from_utf8?

Yeah this isn't the bottleneck so I'm fine with using str::from_utf8. I am a big fan of simd and am a sucker for potential vectorized operations

Parquet already has simdutf8 as (optional) dependency, so I think it makes sense to use it if enabled.

arrow-rs/parquet/Cargo.toml

Line 73 in ff3a2f2

simdutf8 = { version = "0.1.5", optional = true, default-features = false }

alamb · 2025-07-09T22:13:25Z

parquet-variant/src/variant/object.rs

I agree -- it seems unecessary to allocate and copy all the values into a Vec here

alamb · 2025-07-09T22:14:47Z

parquet-variant/src/variant/object.rs

I don't understand why this is faster than simply checking that all the field_ids are less than self.metadata.dictionary_size -- finding the max requires looking at all the items anywyas

alamb · 2025-07-09T22:19:28Z

parquet-variant/src/variant/list.rs

it seems like there is a lot of duplicated code that does about the same thing:
Check that a slice of offsets are all

sorted (potentially)--

Less than some max offset

Point into a valid sub variant

I wonder if it possible to factor it all out into a function like

fn validate_offsets(offset_buffer: &[u8], num_offsets: usize, offset_size: OffsetSize, max_valid_offset: usize) { ... }

Or something 🤔

I plan on following up with a PR that removes this check since we can validate the monotonicity of offsets when accessing variants

parquet-variant/src/variant/metadata.rs

viirya · 2025-07-10T05:44:37Z

parquet-variant/src/variant/metadata.rs

Hmm, is this a new check? Seems exiting VariantMetadata's with_full_validation doesn't have this check?

Yeah, the current validation was written before we supported sorted dictionaries

scovich · 2025-07-10T12:52:40Z

parquet-variant/src/variant/metadata.rs

nit:

Suggested change

.map(|i| {

let field_range = offsets[i - 1]..offsets[i];

value_str.get(field_range)

})

.map(|i| value_str.get(offsets[i - 1]..offsets[i]))

scovich

I would prefer to not materialize id and offset arrays during validation -- there's no way it's free -- but maybe that can be a fast-follow PR?

Also -- some of the efficient iteration techniques the validation uses should probably be backported to the actual iterators?

scovich · 2025-07-10T12:59:32Z

parquet-variant/src/variant/list.rs

We don't need this check -- the loop below does offsets[i-1]..offsets[i] for every i in 1..offsets.len(), and any non-monotonic offset would cause slice_from_slice to return an Err like:?

Tried to extract byte(s) 42..25 from 100-byte buffer

Is it worth making an extra pass over the offsets (which requires materializing them) just to have a slightly nicer error message?

The simplified version would be something like:

let offsets = map_bytes_to_offsets(offset_buffer, self.header.offset_size); if let Some(mut start) = offsets.next() { for end in offsets { ... validate start..end ... start = end; } }

scovich · 2025-07-10T13:10:52Z

parquet-variant/src/variant/metadata.rs

Again, I'm not sure it's worth paying an extra pass for a monotonicity check, when the slicing operations that follow will naturally fail in the presence of non-monotonic offsets?

let offsets = map_bytes_to_offsets(offset_bytes, self.header.offset_size); if let Some(first_offset) = offsets.next() { // Create an iterator over the strings. We must consume the iterator to validate it. let strings = offsets.scan(first_offset, |start, end| { let s = slice_from_slice(value_buffer, start..end); *start = end; Some(s) }); if self.header.is_sorted { // verify the strings are sorted and unique, in addition to being individually valid if let Some(mut a) = strings.next().transpose()? { for b in strings { let b = b?; if a >= b { return Err(... dictionary values are not unique and ordered ...); } a = b; } } } else { // Just verify the strings are all individually valid validate_fallible_iterator(strings)?; } }

This time, an iterator scan works well because we naturally unpack the errors later.

Note: The above does require making slice_from_slice fully generic:

pub(crate) fn slice_from_slice<T, I: SliceIndex<[T]> + Clone + Debug>( bytes: &[T], index: I, ) -> Result<&I::Output, ArrowError> {

scovich · 2025-07-10T13:12:10Z

parquet-variant/src/decoder.rs

Needs a doc comment explaining what it does and the conditions under which it's panic-free?

Sounds good. I took a look at the codegen, the compiler optimizes out the bounds checks so it can not panic under any circumstance

The rustc optimizes and specializes super aggresively -- the specialization you show is for a single-element iterator -- it doesn't even have a loop. But agree that using chunks (rather than chunks_exact) means it shouldn't be able to panic.

Oof, the screenshot should've showed the codegen for chunks_exact.

chunks_exact would never panic. If the slice length that we want to chunk over is not evenly divided by the chunk size, it will omit the remainder elements and can be retrieved by calling remainder() from the iterator.

More formally, ChunksExact will return array.len() // chunk_length elements. ChunksExact::remainder will return a slice with array.len() % chunk_length elements.

chunks would risk a panic if the slice length is not evenly divided by the chunk size. Since, the remainder is directly appended as the last slice in the iterator.

scovich · 2025-07-10T13:33:52Z

parquet-variant/src/variant/object.rs

scovich · 2025-07-10T13:43:51Z

parquet-variant/src/variant/object.rs

We don't need this check. If any field id were out of bounds, the collectat L245 would have already failed.

scovich · 2025-07-10T13:50:03Z

parquet-variant/src/variant/object.rs

Shallow validation already ensured the last offset is in bounds, correct?

scovich · 2025-07-10T13:52:38Z

parquet-variant/src/variant/object.rs

does this not work for some reason?

Suggested change

Ok::<_, ArrowError>(())

Ok(())

(try_for_each does seem to have a pretty weird collect-like signature, but I would have hoped that the previous ? would have fixed the error type...)

scovich · 2025-07-10T13:53:51Z

parquet-variant/src/variant/object.rs

I could inline calls to map_bytes_to_offsets everywhere we loop over field_ids, but that doesn’t seem much better than doing a single allocation

I only see one pass over field_ids? Two possible paths, but each is single-pass?
(the not-sorted-metadata case makes a second pass, but I'm pretty sure it's redundant and will never find a failure -- see other comment)

I think in this case the extra allocation isn’t hurting perf very much

Seems like something we could (should) quantify? For a not-small dictionary I would expect materialization cost to be quite noticeable. Anything big enough to fall out L1 cache would likely see a significant slowdown due to a wave of cache misses on every pass. And that includes not just the offset vec itself (easy enough to prefetch), but also the bytes of the strings and values we examine.

and it makes the code a lot simpler to reason about

I don't think that's necessarily true for the metadata and list cases above (see other comments).

For this case, it would look something like:

let field_ids = map_bytes_to_offsets(field_id_buffer, self.header.field_id_size); if let Some(mut field_id) = field_ids.next() { if self.metadata.is_sorted() { // Since the metadata dictionary has unique and sorted field names... for next_field_id in field_ids { if next_field_id <= field_id { return Err(... field names not sorted ...); } field_id = next_field_id; } } else { // The metadata dictionary can't guarantee uniqueness... ... very similar to the metadata sortedness check: scan + validate_fallible_iterator ... ... probably could even factor out a helper function that both sites can call ... } if field_id >= self.metadata.dictionary_size() { return Err(... field id is not valid ...); } }

viirya · 2025-07-10T16:09:34Z

parquet-variant/src/variant/metadata.rs

Hmm, if there are values like ..., None, Some(a), None, Some(b)..., is it possible that an unordered case like a >= b cannot be detected?

viirya · 2025-07-10T16:14:56Z

parquet-variant/src/variant/object.rs

One question, if is_sorted is false, it means the dictionary cannot guarantee both sortedness and uniqueness? If so, is it still a "dictionary"?

And if so, the name is_sorted is also confusing as it doesn't carry only sortedness.

You're right, but all this naming comes from the variant spec 🤷

Hi @viirya, good question. From the specification:

If sorted_strings is set to 1, strings in the dictionary must be unique and sorted in lexicographic order. If the value is set to 0, readers may not make any assumptions about string order or uniqueness.

viirya · 2025-07-10T16:19:09Z

parquet-variant/src/variant/object.rs

One question, is field id started from 0 and all field ids are continuous?

Yes, per the spec:

A field_id is an index into the dictionary in the metadata

viirya · 2025-07-10T16:30:09Z

parquet-variant/src/variant/object.rs

Btw, existing full validation of VariantObject doesn't check if its field names are sorted, is it missing previously?

I think you're right. The old validation was only ensuring individual fields names were valid, without comparing them for sortedness.

viirya · 2025-07-10T16:32:21Z

parquet-variant/src/variant/object.rs

Field names sortness is different to field id sortness, right? We still can check if field_ids is sorted or not. If it is sorted, we can still just check the last field id?

alamb · 2025-07-10T17:18:09Z

I have sort of lost track of the current state of this PR. Is it something we want to merge and then do follow ons? If so, can we file some tickets to track those follow ons? Or do we want to keep working on this PR?

I would like to improve the benchmarks to more cleanly separate the validation benchmarks from JSON parsing benchmarks.

friendlymatthew · 2025-07-10T17:21:14Z

I have sort of lost track of the current state of this PR. Is it something we want to merge and then do follow ons? If so, can we file some tickets to track those follow ons? Or do we want to keep working on this PR?

I would like to improve the benchmarks to more cleanly separate the validation benchmarks from JSON parsing benchmarks.

Hi, I would like to spend a bit more time on this. @scovich raised some good points about redundant checks which will remove the need to collect offsets.

Here is my checklist for this PR:

avoid materializing offsets + remove redundant checks
better documentation
fix the validation benchmark and move them back to parquet-variant
~~- [ ] make the offset validation DRY by moving it to a freestanding method~~

The simdutf8 stuff can be incorporated as a follow up PR.

scovich · 2025-07-10T17:57:54Z

avoid materializing offsets + remove redundant checks

Honestly, this one feels like a good fast-follow, rather than something that would block the merge? Unless it's super easy/fast to clean up. Perfection as enemy of good and all that. This PR is already a drastic improvement over the current validation. And as @viirya pointed out, this PR adds some validations that were just plain missing before.

Also, as a separate PR we could hopefully even see benchmark results quantifying the impact of the change.

friendlymatthew · 2025-07-10T18:10:47Z

avoid materializing offsets + remove redundant checks

Honestly, this one feels like a good fast-follow, rather than something that would block the merge? Unless it's super easy/fast to clean up. Perfection as enemy of good and all that. This PR is already a drastic improvement over the current validation. And as @viirya pointed out, this PR adds some validations that were just plain missing before.

Also, as a separate PR we could hopefully even see benchmark results quantifying the impact of the change.

Sounds good. I'll get the benchmarks cleaned up and kick the rest over for another PR

alamb · 2025-07-11T02:47:57Z

Looks like there is one final CI check to fix and then I can merge this PR in https://github.com/apache/arrow-rs/actions/runs/16209770665/job/45767524794?pr=7878

I can't push to your PR directly because I don't have permissions in the pydantic fork

If you make PRs from your own fork in the future, I can make changes directly if you think that will help

alamb

Thanks again @friendlymatthew -- I think this is an improvement and it gets us setup for more improvements (the benchmark, etc)

Thus I think we should merge it as soon as we can get the CI to pass

Thanks again @scovich @viirya and @Dandandan for all the help

friendlymatthew · 2025-07-11T02:51:12Z

Looks like there is one final CI check to fix and then I can merge this PR in https://github.com/apache/arrow-rs/actions/runs/16209770665/job/45767524794?pr=7878

I can't push to your PR directly because I don't have permissions in the pydantic fork

If you make PRs from your own fork in the future, I can make changes directly if you think that will help

Hi, I've been trying to figure out why CI is failing. Looking at the warnings, a lot of it is coming from the parquet crate.

The warnings related to parquet-variant come from builder.rs, which this PR doesn't touch.

Fwiw, running cargo doc on main also seems to trigger different warnings.

friendlymatthew · 2025-07-11T02:56:26Z

For example, the latest CI run displays errors like:

Documenting arrow-ord v55.2.0 (/__w/arrow-rs/arrow-rs/arrow-ord)
error: unnecessary parentheses around closure body
--> arrow-ord/src/cmp.rs:276:43
|
276 | let c = |((l, r), n)| ((l ^ r) | (l & r & n));
| ^ ^
|
= note: -D unused-parens implied by -D warnings
= help: to override -D warnings add #[allow(unused_parens)]
help: remove these parentheses
|
276 - let c = |((l, r), n)| ((l ^ r) | (l & r & n));
276 + let c = |((l, r), n)| (l ^ r) | (l & r & n);
|

error: could not document arrow-ord

alamb · 2025-07-11T03:02:44Z

For example, the latest CI run displays errors like:

Documenting arrow-ord v55.2.0 (/__w/arrow-rs/arrow-rs/arrow-ord)
error: unnecessary parentheses around closure body
--> arrow-ord/src/cmp.rs:276:43
|
276 | let c = |((l, r), n)| ((l ^ r) | (l & r & n));
| ^ ^
|
= note: -D unused-parens implied by -D warnings
= help: to override -D warnings add #[allow(unused_parens)]
help: remove these parentheses
|
276 - let c = |((l, r), n)| ((l ^ r) | (l & r & n));
276 + let c = |((l, r), n)| (l ^ r) | (l & r & n);
|

error: could not document arrow-ord

Looks to me like the latest nightly rust got more strict and for some reason we build docs with nightly in this crate

So to reproduce locally I bet you can do

rustup toolchain install nightly
cargo +nightly doc  --document-private-items --no-deps --workspace --all-features

So in other words it is not related to your PR and CI would likely fail on main if we re-ran it

alamb · 2025-07-11T11:12:27Z

@viirya fixed the docs CI failure in this PR ❤️

Fix current CI failure #7898

So I am merging this PR in to keep the code flowing

alamb · 2025-07-11T11:13:04Z

Thanks again. @friendlymatthew can you make sure any follow on tasks we identified are properly tracked with tickets?

Thank you again @scovich @viirya and @Dandandan -- this one took a bit but I think we are on the right track

github-actions bot added the parquet Changes to the parquet crate label Jul 7, 2025

friendlymatthew force-pushed the friendlymatthew/meta-validation branch from f2ff2a3 to 1a9ff6c Compare July 7, 2025 16:02

friendlymatthew force-pushed the friendlymatthew/meta-validation branch from 1a9ff6c to b6af863 Compare July 7, 2025 18:12

scovich reviewed Jul 7, 2025

View reviewed changes

friendlymatthew force-pushed the friendlymatthew/meta-validation branch from 7a581d1 to 1f461da Compare July 8, 2025 02:39

friendlymatthew marked this pull request as draft July 8, 2025 12:27

friendlymatthew force-pushed the friendlymatthew/meta-validation branch 4 times, most recently from 26399ea to 9628c83 Compare July 9, 2025 00:08

friendlymatthew marked this pull request as ready for review July 9, 2025 00:11

friendlymatthew force-pushed the friendlymatthew/meta-validation branch 3 times, most recently from 63fa322 to 646f8a4 Compare July 9, 2025 00:19

alamb reviewed Jul 9, 2025

View reviewed changes

viirya reviewed Jul 10, 2025

View reviewed changes

parquet-variant/src/variant/metadata.rs Outdated Show resolved Hide resolved

viirya reviewed Jul 10, 2025

View reviewed changes

scovich reviewed Jul 10, 2025

View reviewed changes

scovich approved these changes Jul 10, 2025

View reviewed changes

viirya reviewed Jul 10, 2025

View reviewed changes

friendlymatthew force-pushed the friendlymatthew/meta-validation branch 2 times, most recently from 2fc9ed9 to 97610fc Compare July 11, 2025 01:10

friendlymatthew added 7 commits July 10, 2025 21:12

Improve validation perf

e8fd01e

A more finalized version

9135501

Use iter_batched_ref

3cb1e62

Scan over all field ids and check if ids are less than dictionary size

5e630e0

Use str::from_utf8

dda573b

Clean up validation benchmarks

6756a65

Make benches run longer

d7b2596

friendlymatthew force-pushed the friendlymatthew/meta-validation branch from 97610fc to d7b2596 Compare July 11, 2025 01:12

Add comment explaining map_bytes_to_offsets

539722b

alamb approved these changes Jul 11, 2025

View reviewed changes

alamb merged commit b2583b0 into apache:main Jul 11, 2025
12 of 13 checks passed

This was referenced Jul 11, 2025

[Variant] Remove superfluous check when validating monotonic offsets #7900

Closed

[Variant] Avoid collecting offset iterator #7901

Closed

[Variant] Offer simdutf8 as an optional dependency when validating metadata #7902

Closed

This was referenced Jul 28, 2025

[Variant] VariantMetadata, VariantList and VariantObject are too big for Copy #7831

Closed

[Variant] Converting variant to JSON string seems slow #7869

Closed

[Variant] test_json_to_variant_object_very_large takes over 20s #7872

Closed

-                    .map(|i| {
-                        let field_range = offsets[i - 1]..offsets[i];
-                        value_str.get(field_range)
-                    })
+                    .map(|i| value_str.get(offsets[i - 1]..offsets[i]))

[Variant] Speedup validation #7878

[Variant] Speedup validation #7878

Uh oh!

Conversation

friendlymatthew commented Jul 7, 2025 • edited by alamb Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rationale for this change

Uh oh!

friendlymatthew commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alamb commented Jul 7, 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!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

friendlymatthew commented Jul 9, 2025

Uh oh!

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

friendlymatthew Jul 10, 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!

friendlymatthew commented Jul 7, 2025 •

edited by alamb

Loading

friendlymatthew commented Jul 7, 2025 •

edited

Loading

alamb commented Jul 7, 2025 •

edited

Loading

friendlymatthew Jul 10, 2025 •

edited

Loading

friendlymatthew Jul 11, 2025 •

edited

Loading