[bug]: KeyedDecodingContainerProtocol public extension breaks decoding on other consumers.

[alladinian]

Description

Hi there,
just noticed the following issue after importing the AlgoliaSearchClient (Swift - iOS)

Our project relies (among others) to Firebase Firestore (it doesn't matter - but I include this information since many people I guess could be having the same combo).

After importing the search client I got a lot of decoding errors for types that conform to Decodable - specifically type mismatch errors for Decimal properties.

The errors indicated that a string was expected but got a number instead, which was strange (although it does make sense that a string value on DB would be the source for a Decimal) because the actual values on DB (Firestore) were numeric.

After stepping with a debugger I found out about the public extension KeyedDecodingContainerProtocol (Core > Helpers > Extensions) where implementations for Type specific cases were provided.

This is a major problem though because it builds on the assumption that Decimals are stored as strings...

Since this is a public extension, any target that imports the library inherits this problem.

Any ideas or workaround for this issue?

Client

Search

Version

9.14.0

Relevant log output

[Fluf22]

Hey @alladinian 👋🏻

Thank you for your feedback!

Could you give a sample code to repro the issue, please?
It would be easier to fix

Thanks!

[alladinian]

Sure. Thanks for the prompt reply.

Given this structure:

struct Record: Codable {
    let someProperty: Decimal? 
}

and the premise that someProperty is a numeric field in Firestore (or anything else - like a json like { "someProperty" : 123.5 }),

before doing @preconcurrency import Search everything is fine.

After the import, you get:

Could not decode record: typeMismatch(Swift.String, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "someProperty", intValue: nil)], debugDescription: "Expected to decode String but found a number instead.", underlyingError: nil))

Keep in mind that the same applies to the inverse operation (Encoding of Decimal fields)

[Fluf22]

Thank you!

Let me check what can be done

[alladinian]

Here is a full self-contained example that demonstrates the bug (just comment out the extension to see the difference)

algolia_bug.swift.zip

[Fluf22]

Thank you very much, very helpful
Although, your previous explanation was very clear, and I managed to repro the issue ☺️

Is it an option for you to replace Decimal with Double?
I tested it locally, and it'd be a valid workaround, if you can customise your data shape

In the meantime, of course, I'm going to continue looking for a more future-proof resolution for this issue

[alladinian]

Unfortunately that would require massive changes in the code base, but sure that would be a workaround (one that I was hopping to avoid :P )

Thanks very very much. Phenomenal response time.

[Fluf22]

Looks like it has already been fixed in the OpenAPI Generator templates!

Let me do some testing locally, and we will try to release the fixed version by tomorrow eod

I'll send you and update here when it's done

[Fluf22]

Sorry, mixed up my answer above 😅
The linked issue doesn't give a solution, but hints at potential one

Let me work something out

[Fluf22]

Hey @alladinian 👋🏻

I'm going to remove both func altogether, since they resolve a specific issue for OpenAPI Generator that does not apply to us

Feel free to open other issues if you stumble on anything else!
Thanks 🙏🏻

[alladinian]

Hey @Fluf22 👋🏻

Thank you very much.