Aws restJson1 Protocol and Compliance Tests - Lets Discuss

[yisraelU]

A couple of features that we don't support , that are supported by AWS and are tested in the AWS Compliance tests

1. Infinity,Negative Infinity, NaN as values for Float/Double
2. mediaType trait

[Baccata]

We do support the jsonName trait, can you be more specific as to the context where you've noticed it's not supported ?

[kubukoz]

infinity/negative infinity are supported in scala's double too, and @mediaType is supported to some extent AFAIK. I'd suggest reproducing these in some tests.

[yisraelU]

double and float , however the fact that Scala supports them is irrelevant (I mean it is a necessary part , but its not the cause of the problem)

1. Smithy defines them as Strings which results in a Document.DString and will fail when looking for a float

            queryFloat: "Infinity",
            queryDouble: "Infinity",
            queryParamsMapOfStringList: {
                "Float": ["Infinity"],
                "Double": ["Infinity"],
            }
        }

2. we wrap everything in BigDecimal which does not support those and will throw an exception with the following code

val nan = java.lang.Double.NaN
val bigD = BigDecimal(nan)

[yisraelU]

Ok for starters I assumed jsonName is not supported as it doesnt appear in this list https://disneystreaming.github.io/smithy4s/docs/protocols/simple-rest-json/overview
I also did a search for it on the website and could not find a mention.
that said , every single compliance test based on jsonName failed

[Baccata]

@yisraelU jsonName is supported on structures fields : https://github.com/disneystreaming/smithy4s/blob/series/0.17/modules/json/src/smithy4s/http/json/SchemaVisitorJCodec.scala#L908-L912

For the sake of the discussion, I'll ask you (and everyone getting involved) to apply the following approach :

1. If you think something is not supported when it should, please share a repro (by means of a scala-cli script or a PR against this repro adding a unit-test showcasing the problem)
2. If you don't manage to produce a unit-test repro but the compliance-tests are failing, it may be that there is a gap in the compliance-test implementation (as opposed to the protocol implementation), please add a link to the test in question (and if you can, a repro invoking the compliance test by means of a scala-cli script)
3. If you see a gap in the documentation where we have forgotten to indicate that something is supported, please link to the paragraph (or share a screenshot similar to what @kubukoz did).

It's important to abide by this approach for various reasons :

• first of all, it forces people through a rubber-duck process : they might come to some realisations on their own, or learn some things about the implementation during the reproduction of the problem
• it really smoothens communication : as a maintainer, having your hands on a reproduction (rather than a subjective description of the issue) is a huge time saver and reduces risks of misunderstanding and mismatches of semantics between the interlocutors
• it helps people gain experience and teaches them what to expect from contributors if they ever end up becoming main maintainer of an open-source project

[yisraelU]

@Baccata Affirmative to everything you wrote.
And I think you meant this one

smithy4s/modules/json/src/smithy4s/http/json/SchemaVisitorJCodec.scala

Line 1060 in 4c9a81b

private def jsonLabel[A, Z](field: Field[Schema, Z, A]): String =

[Baccata]

Indeed I did

[yisraelU]

I believe its more about how we test for compliance . Ill open a repr to showcase

[yisraelU]

#704

[yisraelU]

My understanding is the default serialization for timestamps in a json under the aws restJson1 protocol is epoch seconds as opposed to simpleRestJson is date time