ParseException when publishing batch to SNS

[Jonathan Schurmann]

Describe the bug

When publishing a batch to SNS, I sometimes see ParseException. This happens when ClockSkewInterceptor is parsing the Date response header to detect clock skew and Date header is using an obsolete format with 2 digits year. When the format is 4 digit year, it works correctly,

Expected behavior

The Date response header should parse the obsolete format correctly.

Current behavior

aws.smithy.kotlin.runtime.time.ParseException: parse `Mon, 22 Apr 24 11:57:18 GMT`: error
at 12: expected exactly 4 digits; found 2
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$takeMNDigitsT$1.invoke(ParserCombinators.kt:180)
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$takeMNDigitsT$1.invoke(ParserCombinators.kt:168)
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$preceded$1.invoke(ParserCombinators.kt:294)
at aws.smithy.kotlin.runtime.time.ParserCombinatorsKt$preceded$1.invoke(ParserCombinators.kt:292)
at aws.smithy.kotlin.runtime.time.ParsersKt.parseRfc5322(Parsers.kt:301)
at aws.smithy.kotlin.runtime.time.Instant$Companion.fromRfc5322(InstantJVM.kt:109)
at aws.smithy.kotlin.runtime.awsprotocol.ClockSkewInterceptor.modifyBeforeAttemptCompletion-gIAlu-s(ClockSkewInterceptor.kt:88)
at aws.smithy.kotlin.runtime.http.interceptors.InterceptorExecutor.modifyBeforeAttemptCompletion-3t6e044(InterceptorExecutor.kt:263)
at aws.smithy.kotlin.runtime.http.middleware.RetryMiddleware.tryAttempt-BWLJW6A(RetryMiddleware.kt:86)
at aws.smithy.kotlin.runtime.http.middleware.RetryMiddleware.access$tryAttempt-BWLJW6A(RetryMiddleware.kt:31)
at aws.smithy.kotlin.runtime.http.middleware.RetryMiddleware$tryAttempt$1.invokeSuspend(RetryMiddleware.kt)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:104)
at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:111)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:99)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:585)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:802)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:706)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:693)\n

Steps to Reproduce

    private suspend fun publishBatch(messages: List<QueueMessage>): List<QueueMessage> {
        val entries = messages.mapIndexed { idx, msg ->
            PublishBatchRequestEntry {
                id = idx.toString()
                message = msg.data
                messageAttributes = msg.messageAttributes()
            }
        }
        return try {
            val resp = client.publishBatch {
                this.topicArn = [e-mail]
                this.publishBatchRequestEntries = entries
            }
            resp.failed?.mapNotNull { it.id }?.map { messages[it.toInt()] } ?: emptyList()
        } catch (e: aws.smithy.kotlin.runtime.http.HttpException) {
            logger.warn(e) {
                "Failed to publish ${entries.size} messages, errorCode:${e.errorCode} isRetryable:${e.sdkErrorMetadata.isRetryable}"
            }
            messages
        }

Possible Solution

Use correct format for the Date header in the SNS response or allow year to be 2 digits.

Context

No response

AWS Kotlin SDK version used

1.0.31

Platform (JVM/JS/Native)

JVM

Operating System and version

N/A

[Ian Botsford]

Thanks for the bug report, @schurmann. I cannot reproduce the error on my end—all the responses I see from SNS include a Date header with 4-digit years (e.g., Thu, 25 Apr 2024 17:41:09 GMT). In which region are you connecting to SNS?

[Jonathan Schurmann]

It occurs very rarely for me, so I suspect it will be difficult to reproduce. I'm connecting to eu-central-1 and haven't tried any other regions. When the Date header is correct, it is in the same format as yours.

FYI: I see that the java sdk swallows any parsing exceptions, so there is a difference in behavior. Not sure if that is intended or not.

[Ian Botsford]

I still cannot reproduce the bad date responses, even in eu-central-1. If I could then I'd be able to communicate the bad values to the SNS team and hopefully resolve the problem at the source.

That said, the ClockSkewInterceptor shouldn't be breaking on bad server dates. I've opened smithy-lang/smithy-kotlin#1082 to gracefully such handle errors.

[github-actions]

⚠️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.