Align metadata propagation through Physical and Logical casts by paleolimbot · Pull Request #23169 · apache/datafusion

paleolimbot · 2026-06-24T19:39:10Z

Which issue does this PR close?

Closes Propagation of metadata through casts can strips extension type from the destination field and can result in invalid extension types #22079
Closes Cast expressions cannot distinguish inherited metadata from an explicitly empty target #24724

Rationale for this change

The logical Expr::Cast and Expr::TryCast have a FieldRef target that was added in #18136 so that logical casts can express a cast to an extension type. In combination with a SQL type planner ( #20676 ) and an optimizer rule, this enabled casting to/from extension types with custom semantics to actually occur. The ability to do this was reverted by #20836 (which removed the original test) and I am not sure that ability ever made it into a release. When investigating this issue, it became clear the logical and physical cast behaviour had diverged with respect to the target field.

What changes are included in this PR?

This PR strips specific metadata keys (extension name and extension metadata) when propagating metadata from the source of a cast to the target (because doing so may result in an invalid destination field that consumers could reject), and propagates all metadata from the (logical) cast target field (e.g., so that a cast to an extension type represented by the cast target field will have a to_field() that communicates the extension type).

For the physical cast, this behaviour is replicated exactly (I hope).

Note that actually casting to an extension type can be implemented with an optimizer rule, planner, or by the mechanism I have in the works in #21071 .

Are these changes tested?

Yes

Are there any user-facing changes?

It was in practice not common to create a Expr::Cast with field metadata internally and thus I don't think users will see metadata changes from the inclusion of metadata from the target field. I would be surprised if stripping the extension name/metadata from the source was disruptive (it was more likely to have caused errors).

Superceeds an earlier but similar attempt ( #22162 ).

paleolimbot · 2026-06-26T19:35:46Z

+    /// Whether to preserve non-extension metadata from the source field.
+    /// When true (default), source metadata is merged with target metadata.
+    /// When false, only the target field's metadata is used.
+    preserve_source_metadata: bool,


This is a little gross feeling to me, but there's at least one place in the code that is counting on Cast::return_field() not to execute its child's return_field(): the virtual row number rewrite requires that the cast strips metadata and does not validate its child's Column (which is invalid, at least where it's tested). There may be a better way here.

Hmm maybe rewrite_file_row_index_expr should not use the CastExpr for this purpose but an "intrinsic" UDF? But I guess this is a different issue then. Not sure how to otherwise avoid that (especially, because we would then require this flag for TryCast if we want feature parity).

I had an alternate suggestion (compute the target metadata needed in the virtual row number code)

paleolimbot · 2026-06-26T19:41:41Z

@adriangb @tschwarzinger @cyberbeam524 You've all kindly waited for me to finish this...happy to iterate on any of your comments here!

tschwarzinger

This looks already great to me! Thank you for finding the time to work on this! 🚀

Sorry, if I have many questions as I am not too familiar with the casting system, even after trying to explore it a bit. Feel free to leave them unanswered.

I think, what would be great is a test that checks the consistency between logical and physical planning. I.e., create a few logical expr and a physical expr pairs with the same casting semantics and check whether they come to the same conclusion. Do you think this would be easily possible?

tschwarzinger · 2026-06-30T09:11:07Z

+    }
+
+    #[test]
+    fn test_try_cast_extension_type_metadata() {


Maybe we can combine these two tests and just parameterize them with Expr::TryCast and Expr::Cast ?

Currently, the test for Expr::Cast seems to check that the metadata of the target field is used, while the test for Expr::TryCast does not test that. We can maybe avoid the nullability check in Expr::TryCast as this has nothing to do with extension types and should be done in a separate tests.

However, this could make the test more "complicated" and keeping them apart might be better. Up to you how you want to deal with it.

I think I did this one!

tschwarzinger · 2026-06-30T09:16:58Z

+    use arrow_schema::extension::{EXTENSION_TYPE_METADATA_KEY, EXTENSION_TYPE_NAME_KEY};
+
+    // Start with source metadata
+    let mut metadata = source_field.metadata().clone();


Just to clarify for myself:

Creating a custom Expr::Cast with custom metadata (e.g., my_custom_key) has never really worked in the sense that my_custom_key becomes part of the output metadata.

And it also does not work in this branch as we only consider the extension name / metadata from the target field.

I think this is fine and if we ever need something like this we can track it in a separate ticket with a use case that requires this sort of casts. I just to make sure that we are not removing the ability to include custom metadata for downstream users.

with custom metadata (e.g., my_custom_key) has never really worked in the sense that my_custom_key becomes part of the output metadata.

Do you mean like adding metadata to the Cast expr itself?

#[derive(Clone, PartialEq, Eq, PartialOrd, Hash, Debug)] pub struct Cast { /// The expression being cast pub expr: Box<Expr>, /// The `DataType` the expression will yield pub field: FieldRef, /// *** New Field: custom metadata ** pub metadata: Metadata, }

We can probably achieve the same thing with a user defined function perhaps

Alias has been able to do this type of metadata reassignment for some time, and I am not sure it is a good use of the Cast to have it messing with metadata (the confusion that led to the current situation is that the cast operator is being used to manipulate metadata, rather than transform a "data type" in the data-type-or-extension-type sense). I'm happy to tweak this to make it consistent...all I personally need is for the target field extension information not to be dropped (so I can insert an optimizer rule that transforms it into a function call).

I do personally like the notion that tje field field unambigiously defines the output Field of the expression 🤔

For arguments sake, and because it seemed a lot cleaner to me, I updated the physical Cast to be explicit about its constituents (i.e., None for metadata passes through from source for backward compatibility, Some(...) forces output, like is required for schema alignment). We were never really casting to a field, we were just using a FieldRef to store three pieces of information.

tschwarzinger · 2026-06-30T09:26:33Z

    cast_options: CastOptions<'static>,
+    /// Whether to preserve non-extension metadata from the source field.
+    /// When true (default), source metadata is merged with target metadata.
+    /// When false, only the target field's metadata is used.


If we keep this flag, should we use this flag too in to_field too? Sorry I am not too familiar with the casting system. And if the answer is yes, should we merge the metadata or just retain the source metadata like we currently do (I think)?

This comes from one specific use that is using the physical cast specifically to strip metadata. I think your later suggestion to remove that usage (and remove this flag) is a good one (but I'll wait for one more opinion on what to do here before I commit).

tschwarzinger · 2026-06-30T09:36:21Z

+    /// Whether to preserve non-extension metadata from the source field.
+    /// When true (default), source metadata is merged with target metadata.
+    /// When false, only the target field's metadata is used.
+    preserve_source_metadata: bool,


Hmm maybe rewrite_file_row_index_expr should not use the CastExpr for this purpose but an "intrinsic" UDF? But I guess this is a different issue then. Not sure how to otherwise avoid that (especially, because we would then require this flag for TryCast if we want feature parity).

tschwarzinger · 2026-06-30T09:39:19Z

+                metadata.remove(EXTENSION_TYPE_METADATA_KEY);
+
+                // Target metadata takes precedence (including extension type metadata)
+                for (k, v) in self.target_field.metadata() {


Here we use the target metadata fields ("custom metadata") but not in cast_output_field, which confuses me a bit.

I think I fixed this (and added a test)

tschwarzinger · 2026-06-30T09:41:08Z

+                EXTENSION_TYPE_NAME_KEY.to_string(),
+                "source.type".to_string(),
+            ),
+            ("source_key".to_string(), "source_value".to_string()),


Maybe adding "target_key" to the target_meta would be beneficial too.

I think I got this one!

alamb · 2026-07-01T15:51:22Z


 [dependencies]
 arrow = { workspace = true }
+arrow-schema = { workspace = true }


why not just use the re-exported types from arrow (why add a new dependency)?

I couldn't figure out how to get arrow_schema::extension::<constants> to show up (I don't think schema is pub exported from arrow). I can also inline the constants for metadata key/value.

This is fine -- probably means we should add some more re-exports to arrow from arrow-schema

alamb

Thanks @paleolimbot and @tschwarzinger -- I can see this is somewhat wacky

I realize the current code takes the metadata from the source field, but that is really confusing to me (as I would expect a cast to produce the output in the target field)

I suspect the challenge is that at some higher levels, when casting to a "data type" that the source metadata can be lost

So what if we made the behavior consistent by:

the Cast expr itself propagate metadata directly from the target_field
Have the higher level aps (like cast_to(data_type)) propagate the source metadata to the target they create

So the semantics of what CastExpr is doing would be clear and consistent

alamb · 2026-07-01T15:55:27Z

+    use arrow_schema::extension::{EXTENSION_TYPE_METADATA_KEY, EXTENSION_TYPE_NAME_KEY};
+
+    // Start with source metadata
+    let mut metadata = source_field.metadata().clone();


with custom metadata (e.g., my_custom_key) has never really worked in the sense that my_custom_key becomes part of the output metadata.

Do you mean like adding metadata to the Cast expr itself?

#[derive(Clone, PartialEq, Eq, PartialOrd, Hash, Debug)] pub struct Cast { /// The expression being cast pub expr: Box<Expr>, /// The `DataType` the expression will yield pub field: FieldRef, /// *** New Field: custom metadata ** pub metadata: Metadata, }

We can probably achieve the same thing with a user defined function perhaps

alamb · 2026-07-01T16:02:12Z

-/// Derives the output field for a cast expression from the source field.
+/// Derives the output field for a cast expression from the source and target fields.
+///
+/// Metadata handling:


Since this is an internal function, I don't think this documentation will be easy to find -- that is not to say it isn't good to have. However I think we should probably also make a more authoritative docs

For example, it would be nice to link to this detail from here

datafusion/datafusion/expr/src/expr_schema.rs

Line 458 in 9e8dd76

/// - **Cast expressions**: determined by the input expression's field metadata handling

I didn't quite get there today, but we can add this to the documentation. (edit: done)

alamb · 2026-07-01T16:07:13Z

+        }
+    }
+
+    /// Create a new `CastExpr` with an explicit target `FieldRef`, using the


can we instead make this a more builder style API -- like

pub fn with_preserve_source_metadata(self, preserve_source_metadata: bool) -> Self { self.preserve_source_metadata = preserve_source_metadata; self }

I think that would make th callsites easier to read

let cast= Cast::new(..) .with_preserve_source_metadata(false)

The physical cast changes let me remove this flag, which I think was kind of ugly anyway. The previous constructors were restored (although maybe we want to make them better).

alamb · 2026-07-01T16:08:38Z

        let source = Arc::new(Column::new(row_index_name, row_index_idx));
        let target_field = Arc::new(Field::new("file_row_index", DataType::Int64, true));
-        Ok(Arc::new(CastExpr::new_with_target_field(
+        Ok(Arc::new(CastExpr::new_with_exact_target_field(


Can you please add a comment here about why it is preservng the source field?

Or is there some way in this code to calculate the desired output metadata here (and attach it to the target field) ?

The physical cast changes let me remove this function and this change dissappeared

alamb · 2026-07-01T16:09:32Z

+    /// Whether to preserve non-extension metadata from the source field.
+    /// When true (default), source metadata is merged with target metadata.
+    /// When false, only the target field's metadata is used.
+    preserve_source_metadata: bool,


I had an alternate suggestion (compute the target metadata needed in the virtual row number code)

alamb · 2026-07-01T16:11:24Z

+    // Start with source metadata
+    let mut metadata = source_field.metadata().clone();
+
+    // Remove any extension type metadata from source - these should not propagate through casts


I worry this is not well documented and we may not be consistent across operators

What do you think about adding documentation on what the expectation for metadata / custom types? I feel like if we had a some good refereence we could then evaluate if the code matched the desired behavior. At the moment I don't know what the overall behavior is supposed to be

We could do this as a separate PR

alamb · 2026-07-01T16:13:45Z

+    if let Some(ext_meta) = target_metadata.get(EXTENSION_TYPE_METADATA_KEY) {
+        metadata.insert(EXTENSION_TYPE_METADATA_KEY.to_string(), ext_meta.clone());
+    }
+


It feels strange to me that when casting to a new Field that the metadata is taken from the source

I think I would personally expect it to come from the target Field (as we are casting "to" that field) -- though I see that is not what the current code does

I updated this to make a bit more sense hopefully...the previous behaviour (pass all metadata through because casts are just modifying the DataType) stays, except we strip extension metadata so that ::VARCHAR has an output type of Utf8. If any metadata is specified, it is authoritative.

Unfortunately updating the storage like I did for the physical cast would be a breaking change here (we maybe shouldn't have used a FieldRef 😬 ), so "the previous behaviour" is a bit cryptically detected (mind you, this cryptic detection previously existed in the physical operator...I just moved it here).

paleolimbot · 2026-07-01T22:13:51Z

(I'm missing TryCast tests here, but I updated this a bit to make it a bit more sane, if a little more verbose. Happy to update whatever here, it just seemed like there was an appeteite to make this cleaner than my hacky previous solution)

edit: I added TryCast tests + sqllogic tests for the practical usages of this, which is basically casting extension types to and from their storage

gene-bordegaray · 2026-08-31T17:30:42Z

I cannot edit the descriotion. But will be reviwing this over pushing my implmeentation at #24725 , I have an open issue, can you mark this as closing the issue: #24724 . Thank you 🙇

paleolimbot · 2026-08-31T17:46:16Z

Sure! Happy to update as needed. I haven't thought about this in a while and it may not be up to date with recent datafusion changes.

gene-bordegaray

I think logical protobuf decoding still drops the cast target metadata added during encoding.

to_proto.rs writes field.metadata() but from_proto.rs rebuilds the field using only arrow_type and nullable.

this should be good after ^ and other comments are addressed. Thank you @paleolimbot 🙇

gene-bordegaray · 2026-08-31T18:01:38Z

+        let source_field = expr.return_field(input_schema)?;
+        let has_extension_metadata = source_field
+            .metadata()
+            .contains_key(EXTENSION_TYPE_NAME_KEY);


should this be:

let metadata = source_field.metadata(); let has_extension_metadata = metadata.contains_key(EXTENSION_TYPE_NAME_KEY || metadata.contains_key(EXTENSION_TYPE_METADATA_KEY);

same with the corresponding line in try_cast

I don't think so...if there's extension metadata but no extension name, I think it's just metadata without any special handling (or more likely, the producer screwed up). Happy to add if you feel strongly.

gene-bordegaray · 2026-08-31T18:07:32Z

                    && !contains_type(target_type, &is_struct)))
        {
-            let Some(target_field) = retain_field_path(cast.target_field(), &field_path)
+            let cast_target_field = cast.target_field();


I think we can use cast_target_field here

gene-bordegaray · 2026-08-31T18:33:42Z

cc: @alamb

gene-bordegaray

forgot to correct the breaking change for 55.1, reminded by @timsaucer thank you 🙇

gene-bordegaray · 2026-08-31T19:30:59Z

-    /// a `DataType`.
+    /// See [`CastExpr::new`] for type-only casts where source metadata should
+    /// pass through.
    pub fn new_with_target_field(


missed this, but since this is going to be in 55.1 patch we cant have the breakin change. Wec ould represent this internally in a way to set up the change in #24725 via something like:

enum CastTarget { TypeOnly(FieldRef), Explicit(FieldRef), } impl CastTarget { fn field(&self) -> &FieldRef { match self {...} } fn is_explicit(&self) -> bool { ... } }

I went with Tim's approach, which was slightly simpler. Introducing a CastTarget is a good idea in general, though.

My main motivation was to get this backported, which required some simplification.

Restore the two public signatures on `CastExpr` that this branch changed, so the metadata fixes can be backported to a patch release: * `CastExpr::new_with_target_field` takes `FieldRef` by value again * `CastExpr::target_field()` returns `&FieldRef` again Both are achieved by storing the target `FieldRef` as before and adding a private `explicit_target` flag that records whether the field was supplied by the caller or synthesized from a `DataType`. That flag carries exactly the information the `Option<HashMap<..>>` / `Option<bool>` pair carried, so `target_metadata()`, `target_nullable()`, `has_explicit_metadata()` and `has_explicit_nullability()` keep their meaning and are derived from it. `Hash`/`PartialEq` compare the same components as before, so the field name still does not participate. `TryCastExpr` is given the same shape for symmetry. Its metadata-aware API is new on this branch, so nothing there is a compatibility constraint. Cast semantics are unchanged: explicit target fields still supply their metadata and nullability verbatim, type-only casts still pass source metadata through with the extension type keys stripped, and the output field name still comes from the source expression. Comparing the public signatures against the merge base with main, the only remaining deltas are additions: + CastExpr::target_metadata / target_nullable + CastExpr::has_explicit_metadata / has_explicit_nullability + TryCastExpr::new_with_target_field / target_metadata / target_field + expressions::try_cast_with_target_field `cast_with_target_field` keeps its `&FieldRef` parameter: `mod cast` is private and it is only re-exported as `pub(crate)`, so it is not part of the public API. Verified: `cargo clippy --workspace --all-targets -- -D warnings` clean, 504/504 sqllogictest files pass, and the unit tests for physical-expr, physical-expr-adapter, physical-plan, pruning, expr, functions and the datafusion core lib all pass.

Keep cast metadata changes non-breaking

paleolimbot · 2026-08-31T21:27:13Z

I think logical protobuf decoding still drops the cast target metadata added during encoding.

Good call! Should be fixed.

I think I got to the comments with Tim's help but happy to update again as well.

timsaucer · 2026-08-31T22:17:20Z

Ok, everything is in the green for CI and we no longer have API changes. I'm going to give it one more review and if nobody has objections I'll probably merge in the morning.

timsaucer

This was a lot of work and a lot of valuable feedback across the community. Thank you @paleolimbot for driving it to completion!

gene-bordegaray

restamp, thanks all @timsaucer @paleolimbot

adriangb · 2026-09-01T06:10:30Z

@paleolimbot thank you for working on this, and thank you @timsaucer for reviewing.

I would like to bring up a question that is probably better asked now, as frustrating as it may be, than after merging: are these really the semantics we want? The main alternative I see is "cast stamps the metadata of the target type", which is what @paleolimbot originally wanted in #22079 and it's what @alamb proposed in #23169 (comment). That's easier to reason about. I was the one that originally pushed us in this direction (merging but stripping extension metadata from the source), but on reflection I don't have any concrete use case for this, I was just defending the status quo (and probably should have spent more time trying to understand the consequences before having @paleolimbot put in all of the work in this PR to work around that). If we wanted to go in this direction (the result field from the cast carries the metadata from the target) I would support that change.

I've put together a series of draft PRs that reach all of the new tests this PR adds, but via the target-stamps rule instead: #24831 -> #24833 -> #24834 / #24835. Stacked, they pass this PR's version of cast_extension_type_metadata.slt verbatim, with the full sqllogictest suite green.

The main con I see to this is that it will be a breaking change in 56. We're somewhat taking a gamble with some use case or user presenting a use case the change broke, but it's a smaller gamble than I expected: across the whole sqllogictest suite the rule change moves 7 assertions, all in metadata.slt, and all of them were added by me in #21390. It's also worth noting #21390 only made try_cast match cast, so half of that surface has only existed since 54. In exchange we are buying ourselves IMO an easier to reason about mental model.

I'm also happy to merge this as is, but I wanted to offer the option in case we are going down a more complex path because of my input.

Separately, and at no fault of this PR, I don't think we should be viewing this as the minimal back port required. Back ports are to fix bugs introduced in that release or recent releases. #24721 does qualify on that basis: the projection metadata loss is a regression found upgrading to 55, which is what I scoped #24831 to (#24721 plus the minimum cast change needed to make the projection fix not regress). But this PR is fixing longstanding inconsistent behavior, which I don't think meets the same bar. I think there's a more narrow version of #24670 which does (see #24670 (comment), #24831).

timsaucer · 2026-09-01T12:11:11Z

@paleolimbot @adriangb @gene-bordegaray Would you all be available tomorrow for the community meeting so we can discuss in real time? I think Adrian makes a strong point about the scope and what should/shouldn't be in a back port.

adriangb · 2026-09-01T12:12:55Z

Yea, I should be able to join. This does seem like that kind of thing worth discussing live.

gene-bordegaray · 2026-09-01T13:05:59Z

yes sounds, good 👍

paleolimbot · 2026-09-01T15:30:49Z

I would like to bring up a question that is probably better asked now, as frustrating as it may be, than after merging: are these really the semantics we want?

I think the semantics in this PR are a standalone improvement over the current situation, which is not consistent between trycast and cast / prevents using DataFusion's SQL parser to do casts into extension types.

I don't think we should be viewing this as the minimal back port required. Back ports are to fix bugs introduced in that release or recent releases.

I've always considered this (the target field of a cast / try cast is not reflected in its return_field()) a bug. Technically it was a bug that was introduced before the correct behaviour was ever released, it just seems that nobody noticed or cared until now.

As always, happy to update this PR if there's a reasonable chance it will merge.

adriangb

I think the semantics in this PR are a standalone improvement over the current situation, which is not consistent between trycast and cast / prevents using DataFusion's SQL parser to do casts into extension types.

I agree it's an improvement over the current state.
The questions I want to make sure we answer are:

Is it the long term behavior we want, or do we want metadata = target field metadata as the long term behavior? As per above I recall this being your preferred behavior.
Is this PR something we want to backport to 55?

Basically if you @paleolimbot think these (this PR) are the right long term semantics we want or we think we should backport something to 55 and this is our best option then I'm 👍🏻 on it.

paleolimbot · 2026-09-01T16:20:59Z

think these (this PR) are the right long term semantics we want or we think we should backport something to 55 and this is our best option then I'm 👍🏻 on it

Whether the target field obliterates incoming metadata or merges it doesn't matter much (except for the extension name, which this PR handles); passthrough is safer because DataFusion has done it for a long time, and can be changed by an optimizer rule if a database needs it. I would love it if this were merged and backported while we're all here looking at it, and any improvements / breaking changes to code or behaviour can be a separate discussion.

github-actions Bot added logical-expr Logical plan and expressions physical-expr Changes to the physical-expr crates labels Jun 24, 2026

paleolimbot mentioned this pull request Jun 24, 2026

Fix extension type metadata propagation through casts #22162

Closed

try the generated answer

c74dd77

paleolimbot force-pushed the cast-metadata-cleanup branch from 7662d3a to c74dd77 Compare June 25, 2026 19:58

don't call return_field for the source info rewrite

b4fdb49

paleolimbot commented Jun 26, 2026

View reviewed changes

paleolimbot marked this pull request as ready for review June 26, 2026 19:37

paleolimbot changed the title ~~Fix extension type metadata propagation through casts~~ Align metadata propagation through Physical and Logical casts Jun 26, 2026

tschwarzinger reviewed Jun 30, 2026

View reviewed changes

alamb reviewed Jul 1, 2026

View reviewed changes

comments

1d1608b

alamb reviewed Jul 1, 2026

View reviewed changes

paleolimbot added 2 commits July 1, 2026 14:43

update the cast representation to remove is_default_target_field()

944cb03

maybe cleaner

83ae9eb

github-actions Bot added the physical-plan Changes to the physical-plan crate label Jul 1, 2026

paleolimbot added 7 commits July 1, 2026 15:05

minimize the diff

6b076ec

align logical cast rules

7d9525d

typo

5e202a7

another typo

b8ddb43

implement try cast

0eb421f

fix build

bbeab9e

fix docs

2adb3cc

paleolimbot added 4 commits July 1, 2026 21:35

ensure try_cast semantics are the same

3aaa9ed

sql logic tests

fb98847

slightly better

efb95ce

better

7d1ceaa

github-actions Bot added the sqllogictest SQL Logic Tests (.slt) label Jul 2, 2026

github-actions Bot added auto detected api change Auto detected API change and removed auto detected api change Auto detected API change labels Aug 31, 2026

gene-bordegaray mentioned this pull request Aug 31, 2026

fix: preserve projection metadata during optimization #24670

Open

gene-bordegaray approved these changes Aug 31, 2026

View reviewed changes

gene-bordegaray suggested changes Aug 31, 2026

View reviewed changes

This was referenced Aug 31, 2026

Keep cast metadata changes non-breaking paleolimbot/datafusion#2

Merged

Non breaking cast metadata #24828

Draft

Merge pull request #2 from timsaucer/non-breaking-cast-metadata

007b8ef

Keep cast metadata changes non-breaking

github-actions Bot removed the physical-plan Changes to the physical-plan crate label Aug 31, 2026

add expr proto fix

e077100

github-actions Bot added the proto Related to proto crate label Aug 31, 2026

timsaucer approved these changes Aug 31, 2026

View reviewed changes

adriangb mentioned this pull request Aug 31, 2026

fix: preserve projection and cast target field metadata #24831

Draft

gene-bordegaray approved these changes Aug 31, 2026

View reviewed changes

This was referenced Sep 1, 2026

fix: make a cast target's metadata authoritative #24833

Draft

fix: arrow_cast must not elide a metadata-changing cast #24834

Draft

feat: give TryCastExpr a target field #24835

Draft

adriangb approved these changes Sep 1, 2026

View reviewed changes

Uh oh!

Conversation

paleolimbot commented Jun 24, 2026 • 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!

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!

paleolimbot commented Jun 26, 2026

Uh oh!

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

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!

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!

paleolimbot Jul 1, 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!

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!

paleolimbot commented Jun 24, 2026 •

edited

Loading

paleolimbot Jul 1, 2026 •

edited

Loading

paleolimbot commented Jul 1, 2026 •

edited

Loading