Parse error on started Journeys

[ojryan]

Describe the bug

We are hitting a parse error when we pull down all the journeys. We have noticed it has something to do with the schedule as it does not happen unless the journey has been started.

Expected behavior

It should pull back all the journeys without error.

Current behavior

We we execute:

        val journeyRequest = ListJourneysRequest {
            this.applicationId = applicationId
        }

        val response = PinpointClient {
            region = Region.US_EAST_1.id()
        }.use { pinpoint -> pinpoint.listJourneys(journeyRequest) }

We get this error:
aws.smithy.kotlin.runtime.time.ParseException: parse 2022-10-06T11:15:40-07:00: error at 4: expected . found -
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$char$1.invoke(ParserCombinators.kt:85)
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$char$1.invoke(ParserCombinators.kt:82)
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$preceded$1.invoke(ParserCombinators.kt:293)
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$preceded$1.invoke(ParserCombinators.kt:292)
at aws.smithy.kotlin.runtime.time.ParsersKt.parseEpoch(Parsers.kt:204)
at aws.smithy.kotlin.runtime.time.Instant$Companion.fromEpochSeconds(InstantJVM.kt:122)
at aws.sdk.kotlin.services.pinpoint.transform.JourneyScheduleDocumentDeserializerKt.deserializeJourneyScheduleDocument(JourneyScheduleDocumentDeserializer.kt:37)
at aws.sdk.kotlin.services.pinpoint.transform.JourneyResponseDocumentDeserializerKt.deserializeJourneyResponseDocument(JourneyResponseDocumentDeserializer.kt:96)
at aws.sdk.kotlin.services.pinpoint.transform.JourneysResponseDocumentDeserializerKt.deserializeJourneysResponseDocument(JourneysResponseDocumentDeserializer.kt:38)
at aws.sdk.kotlin.services.pinpoint.transform.JourneysResponsePayloadDeserializerKt.deserializeJourneysResponsePayload(JourneysResponsePayloadDeserializer.kt:10)
at aws.sdk.kotlin.services.pinpoint.transform.ListJourneysOperationDeserializer.deserialize(ListJourneysOperationDeserializer.kt:28)
at aws.sdk.kotlin.services.pinpoint.transform.ListJourneysOperationDeserializer$deserialize$1.invokeSuspend(ListJourneysOperationDeserializer.kt)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at io.ktor.utils.io.internal.CancellableReusableContinuation.resumeWith(CancellableReusableContinuation.kt:93)
at io.ktor.utils.io.ByteBufferChannel.resumeReadOp(ByteBufferChannel.kt:2121)
at io.ktor.utils.io.ByteBufferChannel.tryTerminate$ktor_io(ByteBufferChannel.kt:383)
at io.ktor.utils.io.ByteBufferChannel.close(ByteBufferChannel.kt:133)
at aws.smithy.kotlin.runtime.io.KtorByteChannelAdapter.close(KtorAdapters.kt:98)
at aws.smithy.kotlin.runtime.http.engine.okhttp.OkHttpUtilsKt$toSdkResponse$httpBody$job$1.invokeSuspend(OkHttpUtils.kt:93)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

Steps to Reproduce

        val journeyRequest = ListJourneysRequest {
            this.applicationId = applicationId
        }

        val response = PinpointClient {
            region = Region.US_EAST_1.id()
        }.use { pinpoint -> pinpoint.listJourneys(journeyRequest) }

Possible Solution

No response

Context

No response

AWS Kotlin SDK version used

Tested on 0.17.5-beta, 0.17.6-beta, 0.17.7-beta

Platform (JVM/JS/Native)

openjdk 11.0.16 2022-07-19 OpenJDK Runtime Environment GraalVM CE 22.2.0 (build 11.0.16+8-jvmci-22.2-b06) OpenJDK 64-Bit Server VM GraalVM CE 22.2.0 (build 11.0.16+8-jvmci-22.2-b06, mixed mode)

Operating System and version

macOS Monterey v12.5.1

[ianbotsf]

Thanks for the bug report, @ojryan. I see the time value the SDK received was 2022-10-06T11:15:40-07:00, which is not an expected timestamp value. Service timestamps should generally be accepted/vended as RFC 3339 timestamps with no UTC offset.

Can you provide more info to help with reproducing the issue? How are the journeys created/started?

[ianbotsf]

It looks like this is at least partially explained by an error in how we interpret the timestamp value in the response. The SDK is erroneously expecting a value in epoch seconds (e.g., 1665080140) when it should be expecting an RFC 3339 date-time in UTC (e.g., 2022-10-06T11:15:40Z).

This still doesn't explain why the value returned from the service includes a non-UTC offset (e.g., -07:00).

[ojryan]

Thank you so much for your quick response. The setup is pretty easy as this happens with any journey that is published. All I am doing publishing the journey. If I look at the "Start" is says "Immediately after publishing". If I look behind that link, the timezone drop down is set to "UTC-07:00 (MST, PDT)".

If I run my code after the journey is created but before publishing, it works perfect.

[ianbotsf]

Thanks for the additional info @ojryan. I'm now able to reproduce the issue in my own account. This seems like incorrect service behavior and I'm working with the Pinpoint team to learn more.

[aajtodd]

@ojryan Can you confirm if this is still an issue in the latest release 0.17.9-beta?

After reviewing how we handle offsets I believe the fix in #714 may have actually been sufficient.

[ojryan]

Yes, this appears be fixed. Thank you so much for addressing! - Octavius Ryan

…

On Oct 31, 2022, at 9:47 AM, Aaron Todd ***@***.***> wrote: @ojryan <https://github.com/ojryan> Can you confirm if this is still an issue in the latest release 0.17.9-beta? After reviewing how we handle offsets I believe the fix in #714 <smithy-lang/smithy-kotlin#714> may have actually been sufficient. — Reply to this email directly, view it on GitHub <#723 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKT7VUD4A6ION5O4TCFXTLWF7LYNANCNFSM6AAAAAARBPYKPY>. You are receiving this because you were mentioned.

[aajtodd]

Thanks for confirming. Closing as fixed