aws-sdk-kotlin icon indicating copy to clipboard operation
aws-sdk-kotlin copied to clipboard

Parse error on started Journeys

Open ojryan opened this issue 3 years ago • 4 comments

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

ojryan avatar Oct 10 '22 16:10 ojryan

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 avatar Oct 10 '22 16:10 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).

ianbotsf avatar Oct 10 '22 17:10 ianbotsf

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)".

2022-10-10_17-19-08 2022-10-10_17-19-59

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

ojryan avatar Oct 10 '22 23:10 ojryan

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.

ianbotsf avatar Oct 11 '22 16:10 ianbotsf

@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.

aajtodd avatar Oct 31 '22 14:10 aajtodd

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 https://github.com/awslabs/smithy-kotlin/issues/714 may have actually been sufficient.

— Reply to this email directly, view it on GitHub https://github.com/awslabs/aws-sdk-kotlin/issues/723#issuecomment-1297201074, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKT7VUD4A6ION5O4TCFXTLWF7LYNANCNFSM6AAAAAARBPYKPY. You are receiving this because you were mentioned.

ojryan avatar Oct 31 '22 14:10 ojryan

Thanks for confirming. Closing as fixed

aajtodd avatar Oct 31 '22 15:10 aajtodd

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.

github-actions[bot] avatar Oct 31 '22 15:10 github-actions[bot]