Add support for int4range, int8range, int4range[], int8range[] #330

rausnitz · 2023-03-05T00:52:03Z

This PR adds support for the int8range Postgres type and the corresponding Swift type Range<Int64>. Postgres comes with built-in support for int8range and five other range types: https://www.postgresql.org/docs/current/rangetypes.html.

The test case I created in this PR demonstrates the new functionality. In short, the range '[-9223372036854775808, 9223372036854775807)'::int8range gets decoded to -9223372036854775808..<9223372036854775807 and the range array ARRAY['[0, 1)'::int8range, '[10, 11)'::int8range] gets decoded to [0..<1, 10..<11].

For now, I only wrote code for int8range and int8range[] because that's what I personally had a need for, but I'd be happy to add support for the other range types (and ClosedRange too), once I get confirmation that there is interest in adding this stuff to PostgresNIO.

Since these types are standard in Postgres, I think they belong in PostgresNIO.

codecov-commenter · 2023-03-05T00:56:30Z

Codecov Report

Merging #330 (a6e1dd8) into main (7a816db) will increase coverage by 1.43%.
The diff coverage is 84.61%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #330      +/-   ##
==========================================
+ Coverage   41.54%   42.97%   +1.43%     
==========================================
  Files         115      118       +3     
  Lines        9436     8242    -1194     
==========================================
- Hits         3920     3542     -378     
+ Misses       5516     4700     -816

Impacted Files	Coverage Δ
...s/PostgresNIO/New/Data/Range+PostgresCodable.swift	`83.82% <83.82%> (ø)`
Sources/PostgresNIO/Data/PostgresDataType.swift	`60.37% <100.00%> (+54.71%)`	⬆️
...s/PostgresNIO/New/Data/Array+PostgresCodable.swift	`71.71% <100.00%> (+0.77%)`	⬆️

... and 115 files with indirect coverage changes

fabianfett

@rausnitz Thanks so much for raising this. Do you want to also add an implementation for PostgresEncodable, PostgresDecodable which will be the way forward. We plan to deprecate PostgresData sooner rather than later.

rausnitz · 2023-03-13T15:13:45Z

Yes, can do.

rausnitz · 2023-03-14T20:15:32Z

@fabianfett The PostgresCodable implementation is done.

I also added support for ClosedRange<Int64>. I reused my Range<Int64> functions instead of implementing binary encoding for ClosedRange<Int64>. Since Range is the canonical form for int8range (see https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-DISCRETE), Postgres would have converted the upper bound anyway.

rausnitz · 2023-03-15T14:45:24Z

One thing to note: the Postgres int8range type can also map to Swift's PartialRangeFrom, PartialRangeThrough, and PartialRangeUpTo types. I didn't add support for those in this PR because I don't need it for my use-case. It wouldn't be difficult to make those types conform to PostgresCodable later without breaking anything.

The part that could become an issue is that I specified the Range type in PostgresData.init(int8Range:) and PostgresData.int8Range. If we wanted to make those generic in the future after this code has been released with Range specified, it would probably be a breaking change at that point. But it's a bit tricky to use the generic RangeExpression because of the associated type, and I didn't know if it was worth coming up with a solution if PostgresData is going away soon anyway.

If you'd prefer me to include PartialRangeFrom, PartialRangeThrough, and PartialRangeUpTo in this PR, let me know.

rausnitz · 2023-03-19T00:58:53Z

The part that could become an issue is that I specified the Range type in PostgresData.init(int8Range:) and PostgresData.int8Range. If we wanted to make those generic in the future after this code has been released with Range specified, it would probably be a breaking change at that point. But it's a bit tricky to use the generic RangeExpression because of the associated type, and I didn't know if it was worth coming up with a solution if PostgresData is going away soon anyway.

Update: The latest commit gets around this issue by adding PostgresInt8RangeExpression.

rausnitz · 2023-03-24T16:20:46Z

The commit that I just pushed makes it straightforward to add the other Postgres range types in the future, not limited to int8range.

rausnitz · 2023-03-24T16:21:59Z

Sources/PostgresNIO/Data/PostgresData+Range.swift

+private let _isLowerBoundInclusive: UInt8 = 0x02
+private let _isUpperBoundInclusive: UInt8 = 0x04


This is mirroring the way these values are defined in the Postgres source code: https://github.com/postgres/postgres/blob/36f40ce2dc66f1a36d6a12f7a0352e1c5bf1063e/src/include/utils/rangetypes.h#L37-L45.

rausnitz · 2023-03-28T22:03:23Z

In the latest commit, I took a different approach that is more straightforward and easier to extend: I created a PostgresRange struct type that contains the properties necessary to represent all the Swift RangeExpression types, with any kind of associated Bound. This turned out to be a lot cleaner and simpler than using protocols to represent Postgres ranges. The new PostgresRange type handles all the encoding to and decoding from binary. So, adding support for more RangeExpression types and Bound types should be very easy, both in the old PostgresData way and the new PostgresCodable way.

This PR now covers two RangeExpression types (Range and ClosedRange) with two Bound types (Int32 and Int64). I can implement all the others supported by Postgres if @fabianfett approves of what I've got so far.

fabianfett

Sorry for taking so long to come back to you. This already is in a nice shape. However there are a few things that I would like to bring into the same shape as the other Encodable, Decodable implementations.

fabianfett · 2023-04-14T11:34:27Z

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

+            throw PostgresDecodingError.Code.failure
+        }
+
+        guard let lowerBound: Bound = postgresRange.lowerBound,


Do we have to check if the range is inclusive here?

See new commit 5aa2b19

fabianfett · 2023-04-14T11:36:07Z

Sources/PostgresNIO/Data/PostgresData+Range.swift

+    /// Postgres automatically converts it to a canonical form.
+    /// Types such as `int4range` get converted to upper-bound-exclusive.
+    /// This method is needed when converting an upper bound to inclusive.
+    var stepDown: (() -> Self)? { get }


Why is that a property and not a simple method? Why should this be optional?

func decrement() -> Self

I changed it to a method here: 1b3d009. (I forget why I made it a property initially).

I also changed it from returning an optional value to making the function throw, which I think is clearer. The reason it can't always return a value is because some Postgres range types are "continuous" and don't have a well-defined step. This includes the built-in Postgres types numrange, tsrange, and tstzrange. Section 8.17.7 of the docs here explains it: https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-DISCRETE.

I originally attempted to do something with Swift's Strideable but couldn't come up with a solution. Here's essentially what I would like to do in the ClosedRange conformance to PostgresDecodable, though this code isn't valid Swift:

if let strideable = upperBound as? Strideable { upperBound = strideable.advanced(by: -1) }

fabianfett · 2023-04-14T11:37:56Z

Sources/PostgresNIO/Data/PostgresData+Range.swift

+
+// MARK: PostgresRange
+
+public struct PostgresRange<B: PostgresRangeBound>: CustomStringConvertible {


Do we need to make this type public?

If I remove public, I see build errors such as generic struct 'PostgresRange' is internal and cannot be referenced from an '@inlinable' function on this line: https://github.com/vapor/postgres-nio/pull/330/files/61b4d5939e43d88ce92406c07645427dd561ac4e#diff-5c0292b699e71becd70812877bc88e53d4e1c18d061b195dacfcdfbb0d8f8faaR17. I could try removing @inlinable but the other existing conformances to PostgresDecodable and PostgresEncodable use it so I figured I should leave it.

Another solution would be to add @usableFromInline in a bunch of places, such as:

@usableFromInline struct PostgresRange<B> { @usableFromInline let lowerBound: B? @usableFromInline let upperBound: B? @usableFromInline let isLowerBoundInclusive: Bool @usableFromInline let isUpperBoundInclusive: Bool init( lowerBound: B?, upperBound: B?, isLowerBoundInclusive: Bool, isUpperBoundInclusive: Bool ) { self.lowerBound = lowerBound self.upperBound = upperBound self.isLowerBoundInclusive = isLowerBoundInclusive self.isUpperBoundInclusive = isUpperBoundInclusive } }

yes please let's go for the second option! I really, really only want to add things to the public API that we need.

fabianfett · 2023-04-14T11:39:17Z

Sources/PostgresNIO/Data/PostgresData+Range.swift

+
+// MARK: PostgresRangeBound
+
+public protocol PostgresRangeBound: PostgresDataConvertible, Comparable {


can we split this into PostgresRangeEncodable and PostgresRangeDecodable? Why does this inherit Comparable?

I just pushed a commit where I limited the usage of Comparable: 3b29899. The reason it's needed at all is because in Swift's RangeExpression types, the Bound has to be Comparable: https://developer.apple.com/documentation/swift/rangeexpression/bound.

I replaced PostgresRangeBound with PostgresRangeEncodable and PostgresRangeDecodable here: 9b8b3ec.

fabianfett · 2023-04-14T11:41:43Z

Sources/PostgresNIO/Data/PostgresData+Range.swift

+// MARK: PostgresData
+
+extension PostgresData {
+    public func range<B>() -> PostgresRange<B>?
+        where B: PostgresRangeBound
+    {
+        guard var value: ByteBuffer = self.value else {
+            return nil
+        }
+
+        return PostgresRange<B>(
+            from: &value,
+            format: self.formatCode
+        )
+    }
+
+    public init<B>(range: PostgresRange<B>)
+    {
+        var buffer = ByteBufferAllocator().buffer(capacity: 0)
+        range.encode(into: &buffer)
+
+        self.init(
+            type: B.rangeType,
+            typeModifier: nil,
+            formatCode: .binary,
+            value: buffer
+        )
+    }
+}
+
+// MARK: PostgresDataConvertible conformance
+
+extension PostgresRange: PostgresDataConvertible where B: PostgresRangeBound {
+    public static var postgresDataType: PostgresDataType { return B.rangeType }
+    public init?(postgresData: PostgresData) {
+        guard var value = postgresData.value else {
+            return nil
+        }
+        self.init(from: &value, format: .binary)
+    }
+    public var postgresData: PostgresData? {
+        return PostgresData(range: self)
+    }
+}
+
+extension RangeExpression where Bound: PostgresRangeBound {
+    public static var postgresDataType: PostgresDataType {
+        return Bound.postgresDataType
+    }
+}
+
+extension Range: PostgresDataConvertible where Bound: PostgresRangeBound {
+    public init?(postgresData: PostgresData) {
+        guard let postgresRange: PostgresRange<Bound> = postgresData.range(),
+            let lowerBound: Bound = postgresRange.lowerBound,
+            let upperBound: Bound = postgresRange.upperBound,
+            postgresRange.isLowerBoundInclusive,
+            !postgresRange.isUpperBoundInclusive
+        else {
+            return nil
+        }
+
+        self = lowerBound..<upperBound
+    }
+
+    public var postgresData: PostgresData? {
+        return PostgresData(range: PostgresRange<Bound>(range: self))
+    }
+}
+
+extension ClosedRange: PostgresDataConvertible where Bound: PostgresRangeBound {
+    public init?(postgresData: PostgresData) {
+        guard let postgresRange: PostgresRange<Bound> = postgresData.range(),
+            let lowerBound: Bound = postgresRange.lowerBound,
+            var upperBound: Bound = postgresRange.upperBound,
+            postgresRange.isLowerBoundInclusive
+        else {
+            return nil
+        }
+
+        if !postgresRange.isUpperBoundInclusive,
+            let steppedDownUpperBound = upperBound.stepDown?()
+        {
+            upperBound = steppedDownUpperBound
+        }
+
+        self = lowerBound...upperBound
+    }
+
+    public var postgresData: PostgresData? {
+        return PostgresData(range: PostgresRange<Bound>.init(closedRange: self))
+    }
+}


Would it be okay for you if we don't add conformance to PostgresDataConvertible? We have already started deprecating this API in #313.

See new commit 52f1d29

fabianfett · 2023-04-14T11:43:18Z

Sources/PostgresNIO/New/Data/Array+PostgresCodable.swift

+extension Range: PostgresArrayDecodable where Bound: PostgresRangeBound {}
+
+extension Range: PostgresArrayEncodable where Bound: PostgresRangeBound {
+    public static var psqlArrayType: PostgresDataType { Bound.rangeType.arrayType! }
+}
+
+extension ClosedRange: PostgresArrayDecodable where Bound: PostgresRangeBound {}
+
+extension ClosedRange: PostgresArrayEncodable where Bound: PostgresRangeBound {
+    public static var psqlArrayType: PostgresDataType { Bound.rangeType.arrayType! }
+}


Having the separation into PostgresRangeEncodable and PostgresRangeDecodable will make this much nicer.

Implemented here: 9b8b3ec.

fabianfett · 2023-04-14T11:44:20Z

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

+extension RangeExpression where Bound: PostgresRangeBound {
+    public static var psqlFormat: PostgresFormat { return .binary }
+}


Can we link the postgres docs here, why this is the case?

I'm actually not sure, though I did notice that all the other implementations of PostgresEncodable return .binary as the value for their psqlFormat.

Is there a scenario where we want to enable the option of .text even though .binary works?

rausnitz · 2023-04-17T21:58:34Z

@fabianfett Thanks for the review! I'll respond to your comments in the next few days.

rausnitz · 2023-04-21T22:29:11Z

To resolve them, I can make those properties and the initializer all @usableFromInline. I'd also make _isLowerBoundInclusive and _isUpperBoundInclusive internal, which probably means I should drop the _ prefix (assuming that convention is for private properties).

I went ahead and did this in 8dc6146, but not sure what to do with let _isLowerBoundInclusive and let _isUpperBoundInclusive. The code works, but now that they're not private, should I make them part of a type instead of making them global?

rausnitz · 2023-04-22T10:46:26Z

I added a new commit aecfdc1 to handle empty ranges, since Postgres treats them as a special case:

-- includes no points (and will be normalized to 'empty')
SELECT '[4,4)'::int4range;

Source: https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-IO.

This means the PostgresDecodable implementation won't find any bound values when parsing the binary. I think it's better to define a defaultBoundValueForEmptyRange than to throw an error.

fabianfett

Really polishing now!

fabianfett · 2023-04-24T08:46:35Z

Sources/PostgresNIO/New/Data/Array+PostgresCodable.swift

+extension Range: PostgresArrayEncodable where Bound: PostgresRangeEncodable {
+    public static var psqlArrayType: PostgresDataType { Bound.psqlRangeType.arrayType! }
+}


I'm afraid this is very dangerous! Can we instead add a PostgresRangeArrayEncodable protocol?

See new commit 71e1042

fabianfett · 2023-04-24T08:48:48Z

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

+
+    /// Postgres does not store any bound values for empty ranges,
+    /// but Swift requires a value to initialize an empty Range<Bound>.
+    static var defaultBoundValueForEmptyRange: Self { get }


What do you think about this name?

fallbackValueForEmptyRange

How about valueForDecodedEmptyRange or valueForEmptyRange? The terms "default" and "fallback" imply that this value is only used if Postgres fails to provide a value, when we know Postgres will never provide a value.

I like valueForEmptyRange.

Done in 884e807

fabianfett · 2023-04-24T08:51:18Z

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

+    }
+}
+
+extension PostgresRange where B: Comparable {


why do we need to constrain B here?

The two initializers in this extension require it.

The Bound value in Range and ClosedRange must be Comparable. Removing where B: Comparable here causes a build error.

See https://developer.apple.com/documentation/swift/range#declaration and https://developer.apple.com/documentation/swift/closedrange#declaration.

fabianfett · 2023-04-24T08:56:12Z

Tests/PostgresNIOTests/New/Data/Range+PSQLCodableTests.swift

+        value.encode(into: &buffer, context: .default)
+        XCTAssertEqual(Range<Int32>.psqlType, .int4Range)
+        XCTAssertEqual(buffer.readableBytes, 17)
+


can we check the binary representation here? Otherwise two a bug in encode could be resolved by a bug in decode?

See new commit 41c2846. Is this what you wanted to see tests for?

fabianfett · 2023-04-24T08:57:04Z

Tests/IntegrationTests/PostgresNIOTests.swift

@@ -341,6 +341,85 @@ final class PostgresNIOTests: XCTestCase {
        XCTAssertEqual(UUID(uuidString: row?[data: "id"].string ?? ""), UUID(uuidString: "123E4567-E89B-12D3-A456-426655440000"))
    }

+    func testInt4Range() throws {


Awesome can we also add an integration test for it here?

Super tiny nit: (Please only fix if you want) We could also use the async syntax for all tests.

fabianfett

Lovely. Can't believe how good this has already gotten. Sadly there is a bit more.

fabianfett · 2023-04-28T07:46:03Z

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

+}
+
+/// A type that can be encoded into a Postgres range array type where it is the bound type
+public protocol PostgresRangeArrayEncodable {


This should inherit from PostgresRangeEncodable, shouldn't it?

See new commit e3c891f

fabianfett · 2023-04-28T07:46:49Z

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

+public protocol PostgresRangeArrayEncodable {
+    static var psqlRangeArrayType: PostgresDataType { get }
+}
+


I wonder if we should also add a PostgresRangeArrayDecodable which inherits from PostgresRangeDecodable to keep symmetry?

Makes sense. Done in e3c891f.

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

fabianfett · 2023-04-28T07:49:49Z

Sources/PostgresNIO/New/Data/Array+PostgresCodable.swift

@@ -85,6 +85,18 @@ extension UUID: PostgresArrayEncodable {
    public static var psqlArrayType: PostgresDataType { .uuidArray }
 }

+extension Range: PostgresArrayDecodable where Bound: PostgresRangeDecodable {}
+
+extension Range: PostgresArrayEncodable where Bound: PostgresRangeEncodable & PostgresRangeArrayEncodable {


Suggested change

extension Range: PostgresArrayEncodable where Bound: PostgresRangeEncodable & PostgresRangeArrayEncodable {

extension Range: PostgresArrayEncodable where Bound: PostgresRangeArrayEncodable {

Done in e3c891f

fabianfett · 2023-04-28T07:50:12Z

Sources/PostgresNIO/New/Data/Array+PostgresCodable.swift

@@ -85,6 +85,18 @@ extension UUID: PostgresArrayEncodable {
    public static var psqlArrayType: PostgresDataType { .uuidArray }
 }

+extension Range: PostgresArrayDecodable where Bound: PostgresRangeDecodable {}


Can we constrain to PostgresRangeArrayDecodable here?

Done in e3c891f

fabianfett · 2023-04-28T07:51:41Z

Tests/IntegrationTests/PostgresNIOTests.swift

@@ -341,6 +341,85 @@ final class PostgresNIOTests: XCTestCase {
        XCTAssertEqual(UUID(uuidString: row?[data: "id"].string ?? ""), UUID(uuidString: "123E4567-E89B-12D3-A456-426655440000"))
    }

+    func testInt4Range() throws {


self.addTeardownBlock { try await conn.close() }

rausnitz · 2023-04-29T22:42:31Z

Lovely. Can't believe how good this has already gotten. Sadly there is a bit more.

I'm enjoying the work and welcome the thorough reviews. I'll have the next batch in soon.

Co-authored-by: Fabian Fett <[email protected]>

fabianfett

Lovely! We should fix the one @usableFromInline to @inlinable. However I would love if @gwynne could take a look as well.

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

gwynne

This is excellent work! I had only the one concern, see below.

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift

Co-authored-by: Fabian Fett <[email protected]>

fabianfett · 2023-05-09T15:06:22Z

@rausnitz this is great work! Thanks so much for pushing through with this. I know I had lot's of comments.

rausnitz · 2023-05-09T16:58:18Z

@fabianfett Thanks for bearing with me through the iterations!

rausnitz added 4 commits March 1, 2023 13:27

provide support for Range<Int64>

fd511f0

use static property for int8range data type

6780c33

add int8range[]

5e5d495

add test for int8range[]

f9af3ec

fabianfett reviewed Mar 13, 2023

View reviewed changes

rausnitz added 2 commits March 13, 2023 18:06

provide support for ClosedRange<Int64>

06fbb82

implement PostgresCodable for int8range types

8be6a7f

rausnitz requested a review from fabianfett March 14, 2023 20:15

fix build issue

080359c

enable future support for other int8range types

388186b

allow PostgresData init with generic range expression

ff74320

rausnitz commented Mar 24, 2023

View reviewed changes

rausnitz added 2 commits March 24, 2023 12:24

fix build for older swift versions

96e13a5

fix another build issue for older swift versions

1209ded

rausnitz marked this pull request as draft March 25, 2023 13:57

add int4range and int4range[]

61b4d59

rausnitz changed the title ~~Add support for int8range and int8range[]~~ Add support for int4range, int8range, int4range[], int8range[] Mar 28, 2023

rausnitz marked this pull request as ready for review March 28, 2023 22:03

fabianfett reviewed Apr 14, 2023

View reviewed changes

rausnitz added 3 commits April 17, 2023 18:51

check Comparable conformance only where needed

3b29899

remove conformance to PostgresDataConvertible

52f1d29

simplify range encoding in tests

a193de0

rausnitz added 2 commits April 21, 2023 18:09

add to and reorganize range tests

26b59f0

change some @usableFromLine to @inlinable

8dc6146

rausnitz requested a review from fabianfett April 21, 2023 22:31

handle empty ranges

aecfdc1

fabianfett reviewed Apr 24, 2023

View reviewed changes

rausnitz added 5 commits April 26, 2023 14:26

prevent crash when decoding ClosedRange from empty pg range

73979db

avoid force-unwrapping two PostgresDataType values

71e1042

add integration tests for int4range and int8range

42174af

test range values encoded to binary

41c2846

rename defaultBoundValueForEmptyRange as valueForEmptyRange

884e807

rausnitz requested a review from fabianfett April 27, 2023 11:30

fabianfett reviewed Apr 28, 2023

View reviewed changes

rausnitz and others added 3 commits April 30, 2023 06:54

improve PostgresRangeArrayEncodable and add PostgresRangeArrayDecodable

e3c891f

limit FixedWithInteger extension to PostgresRangeDecodable types

d5780bb

Co-authored-by: Fabian Fett <[email protected]>

change wait() to await in range tests

618a9d7

rausnitz requested a review from fabianfett April 30, 2023 11:41

fabianfett approved these changes May 8, 2023

View reviewed changes

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift Outdated Show resolved Hide resolved

fabianfett requested a review from gwynne May 8, 2023 12:27

gwynne requested changes May 8, 2023

View reviewed changes

Sources/PostgresNIO/New/Data/Range+PostgresCodable.swift Outdated Show resolved Hide resolved

rausnitz and others added 2 commits May 8, 2023 12:07

Make PostgresRange initializer inlinable

74f4a0c

Co-authored-by: Fabian Fett <[email protected]>

move range flags into struct

a6e1dd8

rausnitz requested a review from gwynne May 8, 2023 20:59

gwynne approved these changes May 8, 2023

View reviewed changes

fabianfett merged commit 8981a23 into vapor:main May 9, 2023

rausnitz deleted the int-range-support branch May 9, 2023 16:58

		private let _isLowerBoundInclusive: UInt8 = 0x02
		private let _isUpperBoundInclusive: UInt8 = 0x04


		// MARK: PostgresRange

		public struct PostgresRange<B: PostgresRangeBound>: CustomStringConvertible {


		// MARK: PostgresRangeBound

		public protocol PostgresRangeBound: PostgresDataConvertible, Comparable {

	extension Range: PostgresArrayEncodable where Bound: PostgresRangeEncodable & PostgresRangeArrayEncodable {
	extension Range: PostgresArrayEncodable where Bound: PostgresRangeArrayEncodable {

Uh oh!

Add support for int4range, int8range, int4range[], int8range[] #330

Add support for int4range, int8range, int4range[], int8range[] #330

Uh oh!

Conversation

rausnitz commented Mar 5, 2023

Uh oh!

codecov-commenter commented Mar 5, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

fabianfett left a comment

Choose a reason for hiding this comment

Uh oh!

rausnitz commented Mar 13, 2023

Uh oh!

rausnitz commented Mar 14, 2023

Uh oh!

rausnitz commented Mar 15, 2023

Uh oh!

rausnitz commented Mar 19, 2023

Uh oh!

rausnitz commented Mar 24, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rausnitz commented Mar 28, 2023

Uh oh!

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

Choose a reason for hiding this comment

Uh oh!

rausnitz commented Apr 17, 2023

Uh oh!

rausnitz commented Apr 21, 2023

Uh oh!

rausnitz commented Apr 22, 2023

Uh oh!

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

codecov-commenter commented Mar 5, 2023 •

edited

Loading