Core: Detect and merge duplicate DVs for a data file and merge them before committing by amogh-jahagirdar · Pull Request #15006 · apache/iceberg

amogh-jahagirdar · 2026-01-09T03:34:17Z

While generally, writers are expected to merge DVs for a given data file before attempting to commit, we probably want to have a safeguard in the commit path in case this assumption is violated. This has been observed when AQE is enabled in Spark and a data file is split across multiple tasks (really just depends on how files and deletes are split); then multiple DVs are produced for a given data file, and then committed. Currently, after that commit reads would fail since the DeleteFileIndex detects the duplicates and fails on read.

Arguably, there should be a safeguard on the commit path which detects duplicates and fixes them up to prevent any invalid table states. Doing this behind the API covers any engine integration using the library.

This change updates MergingSnapshotProducer to track duplicate DVs for a datafile, and then merge them and produces a Puffin file per DV. Note that since we generally expect duplicates to be rare, we don't expect there to be too many small Puffins produced, and we don't add the additional logic to coalesce into larger files. Furthermore, these can later be compacted. In case of large scale duplicates, then engines should arguably fix those up before handing off to the commit path.

amogh-jahagirdar · 2026-01-09T03:38:11Z

Still cleaning some stuff up, so leaving in draft but feel free to comment. But basically there are some cases in Spark where a file can be split across multiple tasks, and if deletes happen to touch every single part in the task we'd incorrectly produce multiple DVs for a given data file (discovered this recently with a user when they had Spark AQE enabled, but I think file splitting can happen in more cases).

We currently throw on read in such cases, but ideally we can try and prevent this on write by detecting and merging pre-commit.

The reason this is done behind the API is largely so that we are defensive from a library perspective that in case an engine/integration happens to produce multiple DVs, we can at least fix it up pre-commit.

In the case there are too many to reasonably rewrite on a single node, then engines could do distributed writes to fix up before handing off the files to the API, but arguably from a library perspective it seems reasonable to pay this overhead to prevent bad commits across any integration.

core/src/main/java/org/apache/iceberg/io/OutputFileFactory.java

amogh-jahagirdar · 2026-01-09T23:20:09Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

-      addedFilesSummary.addedFile(spec, file);
      hasNewDeleteFiles = true;
      if (ContentFileUtil.isDV(file)) {
        newDVRefs.add(file.referencedDataFile());


Probably keep a boolean in-case we detect a duplicate. That way we don't have to pay the price of grouping by referenced file everytime to detect possible duplicates; only if we detect it at the time of adding it, we can do the dedupe/merge

We also could just keep a mapping specific for duplicates. That shrinks down how much work we need to do because instead of trying to group by every referenced data file in case of duplicates, we just go through the duplicates set. It's maybe a little more memory but if we consider that we expect duplicates to generally be rare it feels like a generally better solution

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

amogh-jahagirdar · 2026-01-12T03:16:09Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

    DeleteFileSet deleteFiles =
        newDeleteFilesBySpec.computeIfAbsent(spec.specId(), ignored -> DeleteFileSet.create());
-    if (deleteFiles.add(file)) {
-      addedFilesSummary.addedFile(spec, file);


because we may be merging duplicates, we don't update the summary for delete files until after we dedupe and are just about to write the new manifests

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

amogh-jahagirdar · 2026-01-12T03:30:57Z

spark/v4.0/spark/src/test/java/org/apache/iceberg/spark/source/TestPositionDeletesTable.java

    Pair<List<PositionDelete<?>>, DeleteFile> deletesA =
        deleteFile(tab, dataFileA, new Object[] {"aa"}, new Object[] {"a"});
    Pair<List<PositionDelete<?>>, DeleteFile> deletesB =
-        deleteFile(tab, dataFileA, new Object[] {"bb"}, new Object[] {"b"});


This fix surfaced an issue in some of the TestPositionDeletesTable tests where we were setting the wrong data file for delete file; we'd just add a DV for the same data file, and then it'd get merged with the new logic , and break some of the later assertions.

amogh-jahagirdar · 2026-01-12T03:37:47Z

...4.0/spark/src/test/java/org/apache/iceberg/spark/actions/TestRemoveDanglingDeleteAction.java

    // Add Data Files with EQ and POS deletes
    DeleteFile fileADeletes = fileADeletes();
    DeleteFile fileA2Deletes = fileA2Deletes();
-    DeleteFile fileBDeletes = fileBDeletes();


This test had to be fixed after the recent changes because the file paths for data file B and B2 were set to the same before, so the DVs for both referenced the same file (but that probably wasn't the intention of these tests) so it was a duplicate. After this change we'd merge the DVs in the commit, and then it'd actually get treated as a dangling delete and fail some of the assertions.

Since these tests are just testing the eq. delete case we could just simplify it by removing the usage of fileB deletes, it's a more minimal test that tests the same thing.

Also note, generally I'd take this in a separate PR but I think there's a good argument that this change should be in a 1.10.2 patch release to prevent invalid table states; in that case we'd need to keep these changes together.

RussellSpitzer · 2026-01-13T15:16:20Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

+              String referencedLocation = dvsToMergeForDataFile.getKey();
+              mergedDVs.put(
+                  referencedLocation,
+                  mergeAndWriteDV(referencedLocation, dvsToMergeForDataFile.getValue()));


LIttle weird that we are now writing delete vectors on the driver?

spark/v3.4/spark/src/test/java/org/apache/iceberg/spark/source/TestPositionDeletesTable.java

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

core/src/test/java/org/apache/iceberg/TestRowDelta.java

RussellSpitzer · 2026-01-13T15:54:01Z

core/src/test/java/org/apache/iceberg/TestRowDelta.java

+    OutputFileFactory fileFactory =
+        OutputFileFactory.builderFor(table, 1, 1).format(FileFormat.PUFFIN).build();
+
+    DeleteFile deleteFile1 = dvWithPositions(dataFile, fileFactory, 0, 2);


Probably doesn't matter but in the real world these could also potentitally have existing overlapping deletes
Ie
Task 1 has existing DV and merges a few new Deletes
Task 2 has existing DV and merges a few new deletes

I think the logic is fine though

RussellSpitzer · 2026-01-13T16:01:37Z

I'm mostly on board here but I have a few concerns,

I Think the implementation here is trying to be efficient with memory usage by populating the map only if a duplicate is found, but I'm not sure it's really saving us all that much when every time we do hit a match we have to scan the entire list dv's again to find the dv which is the duplicate. I'd consider whether just keeping a mapping of reference data files to delete vectors is that much more expensive. It would make the lookup much simpler
Intrinsically we are cleaning up after something which shouldn't be happening. Given that we know fixing this behavior in spark may take a while or ... may just be impossible without further mods, I think having a fix here is better than throwing an exception (which could be another solution) but It feels weird that we are rewriting things from the driver here. I think this is now the first time that the Spark integration writes data/delete files from the driver and that feels a little weird to me.
I agree with the requests for logging, this is probably really not good for performance and we should have some notes that it is happening for users although that's not really important now unless we have a way to avoid it from spark.

rdblue · 2026-01-13T18:15:00Z

spark/v3.4/spark/src/test/java/org/apache/iceberg/spark/source/TestPositionDeletesTable.java

    // Add position deletes for both partitions
    Pair<List<PositionDelete<?>>, DeleteFile> deletesA = deleteFile(tab, dataFileA, "a");
-    Pair<List<PositionDelete<?>>, DeleteFile> deletesB = deleteFile(tab, dataFileA, "b");
+    Pair<List<PositionDelete<?>>, DeleteFile> deletesB = deleteFile(tab, dataFileB, "b");


These tests are failing with the fix to core, right? I think we generally try to update one Spark version per commit unless there are failures that would leave main in a broken state.

Yeah that's right, it's failing with the changes to core in this PR because the test was setting up duplicates (unintentionally as far as I can tell) and now we'd be merging them and breaking some of the assertions in the test.

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

amogh-jahagirdar · 2026-02-24T15:51:30Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

-  private final Map<Integer, DeleteFileSet> newDeleteFilesBySpec = Maps.newHashMap();
-  private final Set<String> newDVRefs = Sets.newHashSet();
+  private final List<DeleteFile> v2Deletes = Lists.newArrayList();
+  private final Map<String, List<DeleteFile>> dvsByReferencedFile = Maps.newLinkedHashMap();


I commented this elsehwere but the reason this field is a LinkedHashMap is because there's quite a lot of tests which verify the exact ordering of entries in a manifest. I do think we should change those tests because we really shouldn't be guaranteeing any ordering in the entries in the output manifests but that's a larger change. The current implementation which tracks newDeleteFilesBySpec uses a DeleteFileSet which is an insertion-ordering preserving structure.

I am not sure about the ordering here, since I think that is something we may want to guarentee or at least make determinsitic in the future. We can always talk about that later though.

No problems with this usage here of LinkedHashMap

rdblue · 2026-02-24T23:28:04Z

core/src/main/java/org/apache/iceberg/deletes/Deletes.java

    return toPositionIndexes(posDeletes, null /* unknown delete file */);
  }

+  public static PositionDeleteIndex readDV(DeleteFile deleteFile, FileIO fileIO) {


Should this be here or in DVUtil?

Deletes seems to be utilities for working with position delete structs coming from an engine. DVUtil seems more appropriate to me.

rdblue · 2026-02-24T23:29:51Z

core/src/main/java/org/apache/iceberg/DVUtil.java

+   * Merges duplicate DVs for the same data file and writes the merged DV Puffin files. If there is
+   * exactly 1 DV for a given data file then it is return as is
+   *
+   * @param dvsByFile map of data file location to DVs


Missing quite a few params here.

rdblue · 2026-02-24T23:31:30Z

core/src/main/java/org/apache/iceberg/DVUtil.java

+   */
+  static List<DeleteFile> mergeAndWriteDVsIfRequired(
+      Map<String, List<DeleteFile>> dvsByFile,
+      Supplier<OutputFile> dvOutputFile,


Since this has a FileIO, it's a little awkward to have a Supplier<OutputFile> passed in since a big part of that is the job of FileIO. Also, if this supplier is only called once then it doesn't need to be a supplier. What about passing a string location instead?

rdblue · 2026-02-24T23:33:20Z

core/src/main/java/org/apache/iceberg/DVUtil.java

+   * @return a list containing both any newly merged DVs and any DVs that are already valid
+   */
+  static List<DeleteFile> mergeAndWriteDVsIfRequired(
+      Map<String, List<DeleteFile>> dvsByFile,


dvsByReferencedFile?

rdblue · 2026-02-24T23:42:41Z

core/src/main/java/org/apache/iceberg/DVUtil.java

+    for (int i = 0; i < duplicateDVPositions.length; i++) {
+      PositionDeleteIndex dvPositions = duplicateDVPositions[i];
+      DeleteFile dv = duplicateDVs.get(i);
+      mergedIndexByFile.merge(


I think this is correct, but I find a more straightforward implementation that uses get instead of merge easier to read:

Map<String, PositionDeleteIndex> mergedDVs = Maps.newHashMap(); for (int i = 0; i < duplicatedDVPositions.length; i++) { PositionDeleteIndex previousDV = mergedDVs.get(duplicateDVs.get(i).referencedDataFile()); if (previousDV != null) { previousDV.merge(duplicatedDVPositions[i]); } else { mergedDVs.put(delete.referencedDataFile(), duplicatedDVPositions[i]); } }

rdblue · 2026-02-24T23:46:53Z

core/src/main/java/org/apache/iceberg/DVUtil.java

+
+    List<DeleteFile> mergedDVs = Lists.newArrayList();
+    Map<String, PartitionSpec> specByFile = Maps.newHashMap();
+    Map<String, StructLike> partitionByFile = Maps.newHashMap();


Rather than 2 maps and lookups, why not use Map<String, Pair<PartitionSpec, StructLike>>?

rdblue · 2026-02-25T00:23:03Z

core/src/main/java/org/apache/iceberg/DVUtil.java

+      FileIO fileIO,
+      Map<Integer, PartitionSpec> specs,
+      ExecutorService pool) {
+    Map<String, List<DeleteFile>> duplicateDVsByFile =


There are a couple of things that make this method fairly complicated. First, using a map of lists ends up causing this to do a fair amount of stream manipulation. Using a Guava multimap cleans that up quite a bit.

Second, this doesn't need to process the input map multiple times. This is cleaner if you process it once, keep the DVs that don't need to be merged in an output list, and also accumulate the partition and sequence number info for later at the same time. Doing that also simplifies the write and validate methods because you can identify the expected data sequence number and partition information here rather than complicating the loops in later methods.

Here's what I came up with:

static List<DeleteFile> mergeAndWriteDVsIfRequired( Map<String, List<DeleteFile>> dvsByFile, Supplier<OutputFile> dvOutputFile, FileIO fileIO, Map<Integer, PartitionSpec> specs, ExecutorService pool) { List<DeleteFile> finalDVs = Lists.newArrayList(); Multimap<String, DeleteFile> duplicates = Multimaps.newListMultimap(Maps.newHashMap(), Lists::newArrayList); Map<String, Pair<PartitionSpec, StructLike>> partitions = Maps.newHashMap(); for (Map.Entry<String, List<DeleteFile>> entry : dvsByFile.entrySet()) { if (entry.getValue().size() > 1) { duplicates.putAll(entry.getKey(), entry.getValue()); DeleteFile first = entry.getValue().get(0); partitions.put(entry.getKey(), Pair.of(specs.get(first.specId()), first.partition())); } else { finalDVs.addAll(entry.getValue()); } } if (duplicates.isEmpty()) { return finalDVs; } validateCanMerge(duplicates, partitions); Map<String, PositionDeleteIndex> deletes = readAndMergeDVs(duplicates.values().toArray(DeleteFile[]::new), fileIO, pool); finalDVs.addAll(writeDVs(deletes, partitions, dvOutputFile)); return finalDVs; }

core/src/main/java/org/apache/iceberg/DVUtil.java

rdblue · 2026-02-25T00:33:27Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

      cachedNewDeleteManifests.clear();
+      // On cache invalidation of delete files, clear the whole summary.
+      // Since the summary contained both data files and DVs, add back the data files.
+      addedFilesSummary.clear();


Is this an added files summary, or is it a commit summary? Maybe we should change the name to be more clear.

rdblue · 2026-02-25T00:35:34Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

+      // On cache invalidation of delete files, clear the whole summary.
+      // Since the summary contained both data files and DVs, add back the data files.
+      addedFilesSummary.clear();
+      newDataFilesBySpec.forEach(


I think it would be better not to handle data files in newDeleteFilesAsManifests. It isn't obvious that this method is going to clear the data file summary and no one would look here for it. Why not keep a separate summary for data files and merge it with the deletes for the final summary? The data file one doesn't need to change.

rdblue · 2026-02-25T00:44:54Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

+            dvsByReferencedFile,
+            () -> {
+              String filename = FileFormat.PUFFIN.addExtension(String.valueOf(snapshotId()));
+              return fileIO.newOutputFile(ops().locationProvider().newDataLocation(filename));


I think we should add a little more to this path. This doesn't show what the file is and will overwrite the same file name on each retry.

I would use an instance field so that we can embed a file counter:

private final AtomicInteger dvMergeAttempt = new AtomicInteger(0); String filename = FileFormat.PUFFIN.addExtension(String.format("merged-dvs-%s-%s", snapshotId(), dvMergeAttempt.incrementAndGet()));

rdblue · 2026-02-25T00:45:18Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

+            ThreadPools.getDeleteWorkerPool());
+
+    return finalDVs.stream()
+        .map(file -> Delegates.pendingDeleteFile(file, file.dataSequenceNumber()))


As I noted, I'd prefer to remove the wrapper here.

rdblue · 2026-02-27T00:17:15Z

core/src/main/java/org/apache/iceberg/deletes/BaseDVFileWriter.java


  private PuffinWriter newWriter() {
-    EncryptedOutputFile outputFile = fileFactory.newOutputFile();
+    OutputFile outputFile = dvOutputFile.get();


I think there's an existing problem with this class. It doesn't need to be fixed right now but we should follow up.

The issue is that this doesn't handle encryption key metadata when it creates DeleteFile instances in createDV. I would expect this to pass the output file's encryption key metadata (if it is an EncryptedOutputFile) to the delete file builder via withEncryptionKeyMetadata. But that isn't called.

I think that this class will still create encrypted streams because it calls EncryptedOutputFile#encryptingOutputFile to produce output streams. It just doesn't get the key metadata and pass it on.

This isn't a blocker for this commit since it's an existing bug, but we shouldn't leave it this way because it could create DVs that are encrypted and unrecoverable.

@aokolnychyi, you may want to take a look.

RussellSpitzer · 2026-02-27T20:33:16Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

  protected boolean addsDeleteFiles() {
-    return !newDeleteFilesBySpec.isEmpty();
+    return !v2Deletes.isEmpty()
+        || dvsByReferencedFile.values().stream().anyMatch(dvs -> !dvs.isEmpty());


How do we get empty "dvs" here? Shouldn't it always have contents?

Yes, it should. This is a defensive check.

RussellSpitzer · 2026-02-27T20:57:52Z

core/src/test/java/org/apache/iceberg/TestRowDelta.java

+                .collect(Collectors.toList()));
+    assertThat(committedEqDelete).isNotNull();
+    assertThat(committedEqDelete.content()).isEqualTo(FileContent.EQUALITY_DELETES);
+  }


There are a few other validations we could test here as well, (since we spent the time to add them)

Same file name different specs
Sequence number mismatch

I forgot what else you added :)

Asked claude,

Mismatched sequence numbers -- two DVs for the same data file have different dataSequenceNumber() values. The validation at line 110-115 should throw IllegalArgumentException but this is never exercised.

Mismatched spec IDs -- two DVs for the same data file reference different partition specs (line 117-122). Not tested.

Mismatched partition tuples -- same spec but different partition values (line 124-129). Not tested.

rdblue · 2026-02-27T21:15:39Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

-  private final SnapshotSummary.Builder addedFilesSummary = SnapshotSummary.builder();
+  private final SnapshotSummary.Builder addedDataFilesSummary = SnapshotSummary.builder();
+  private final SnapshotSummary.Builder addedDeleteFilesSummary = SnapshotSummary.builder();
+


Nit: unnecessary whitespace change.

rdblue · 2026-02-27T21:17:39Z

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java

      // this triggers a rewrite of all delete manifests even if there is only one new delete file
      // if there is a relevant use case in the future, the behavior can be optimized
      cachedNewDeleteManifests.clear();
+      // On cache invalidation of delete files, clear the summary.


I think this comment is obvious from the call below. I think the idea is right to have a comment here: why is it necessary to clear the summary? That's because the summary can't be generated until after DV merge happens and any new DV could require a merge. So the summary is built each time DV manifests are written.

rdblue

Looks good to me! Russell pointed out some test cases that should be added and I found a couple of minor things that are nice-to-have.

github-actions bot added the core label Jan 9, 2026

github-actions bot added the spark label Jan 9, 2026

amogh-jahagirdar commented Jan 9, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/io/OutputFileFactory.java Outdated Show resolved Hide resolved

amogh-jahagirdar commented Jan 9, 2026

View reviewed changes

singhpk234 reviewed Jan 10, 2026

View reviewed changes

amogh-jahagirdar commented Jan 10, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Outdated Show resolved Hide resolved

geruh reviewed Jan 11, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Outdated Show resolved Hide resolved

amogh-jahagirdar force-pushed the always-merge-duplicates-on-driver branch from 374b567 to c04d0e0 Compare January 11, 2026 20:02

amogh-jahagirdar commented Jan 11, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Outdated Show resolved Hide resolved

geruh reviewed Jan 11, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Show resolved Hide resolved

amogh-jahagirdar commented Jan 12, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Outdated Show resolved Hide resolved

amogh-jahagirdar commented Jan 12, 2026

View reviewed changes

amogh-jahagirdar marked this pull request as ready for review January 12, 2026 17:15

amogh-jahagirdar changed the title ~~Core: Merge DVs referencing the same data files as a safeguard~~ Core: Track duplicate DVs for data file and merge them before committing Jan 12, 2026

amogh-jahagirdar requested review from RussellSpitzer, aokolnychyi, nastra and rdblue January 12, 2026 17:35

RussellSpitzer reviewed Jan 13, 2026

View reviewed changes

spark/v3.4/spark/src/test/java/org/apache/iceberg/spark/source/TestPositionDeletesTable.java Show resolved Hide resolved

RussellSpitzer reviewed Jan 13, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Outdated Show resolved Hide resolved

RussellSpitzer reviewed Jan 13, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Outdated Show resolved Hide resolved

RussellSpitzer reviewed Jan 13, 2026

View reviewed changes

core/src/test/java/org/apache/iceberg/TestRowDelta.java Show resolved Hide resolved

RussellSpitzer reviewed Jan 13, 2026

View reviewed changes

rdblue reviewed Jan 13, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/MergingSnapshotProducer.java Outdated Show resolved Hide resolved

amogh-jahagirdar force-pushed the always-merge-duplicates-on-driver branch 4 times, most recently from f39d27e to afdb314 Compare February 24, 2026 16:00

amogh-jahagirdar commented Feb 24, 2026

View reviewed changes

fix summary stats on cache invalidation, address simplifications

1efc041

amogh-jahagirdar force-pushed the always-merge-duplicates-on-driver branch from afdb314 to 1efc041 Compare February 24, 2026 17:06

rdblue reviewed Feb 24, 2026

View reviewed changes

rdblue reviewed Feb 25, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/DVUtil.java Show resolved Hide resolved

rdblue reviewed Feb 25, 2026

View reviewed changes

core/src/main/java/org/apache/iceberg/DVUtil.java Show resolved Hide resolved

rdblue reviewed Feb 25, 2026

View reviewed changes

rdblue reviewed Feb 27, 2026

View reviewed changes

amogh-jahagirdar force-pushed the always-merge-duplicates-on-driver branch from afb63b6 to eab1ca5 Compare February 27, 2026 15:00

address feedback

380d09e

amogh-jahagirdar force-pushed the always-merge-duplicates-on-driver branch from eab1ca5 to 380d09e Compare February 27, 2026 15:08

RussellSpitzer reviewed Feb 27, 2026

View reviewed changes

RussellSpitzer approved these changes Feb 27, 2026

View reviewed changes

rdblue reviewed Feb 27, 2026

View reviewed changes

rdblue approved these changes Feb 27, 2026

View reviewed changes

Conversation

amogh-jahagirdar commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

amogh-jahagirdar commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amogh-jahagirdar Jan 10, 2026 • 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

amogh-jahagirdar Jan 12, 2026 • 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RussellSpitzer commented Jan 13, 2026

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!

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!

rdblue Feb 25, 2026 • 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!

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!

amogh-jahagirdar commented Jan 9, 2026 •

edited

Loading

amogh-jahagirdar commented Jan 9, 2026 •

edited

Loading

amogh-jahagirdar Jan 10, 2026 •

edited

Loading

amogh-jahagirdar Jan 12, 2026 •

edited

Loading

rdblue Feb 25, 2026 •

edited

Loading

RussellSpitzer Feb 27, 2026 •

edited

Loading