Removed sequenceToken from PeriodicBatchingSinkImplementationCallback

[VadymLevkovskyi]

PeriodicBatchingSinkImplementationCallback class and related tests are fixed

Code related to issue #142

[wparad]

There are a lot more places to update if this is indeed true. See the message in the docs:

The sequence token is now ignored in PutLogEvents actions. PutLogEvents actions are always accepted and never return InvalidSequenceTokenException or DataAlreadyAcceptedException even if the sequence token is not valid. You can use parallel PutLogEvents actions on the same log stream.

Is the sequence token required by the library? What happens for the minimum supported AWSSDK.CloudWatchLogs version if the SequenceToken isn't specified?

[VadymLevkovskyi]

There are a lot more places to update if this is indeed true. See the message in the docs:

The sequence token is now ignored in PutLogEvents actions. PutLogEvents actions are always accepted and never return InvalidSequenceTokenException or DataAlreadyAcceptedException even if the sequence token is not valid. You can use parallel PutLogEvents actions on the same log stream.

Is the sequence token required by the library? What happens for the minimum supported AWSSDK.CloudWatchLogs version if the SequenceToken isn't specified?

Brilliant questions, thanks for highlighting them!

Regarding removing catches for mentioned exceptions - I saw it but really wasn't sure if the sequence token is the only source throwing them. Would suggest to remove them few versions later, but don't insist.

Regarding AWSSDK.CloudWatchLogs version that introduced this change - from changelog documentation it is 3.7.454.0 (2023-01-04 19:21 UTC).

Regarding necessity of sequence token - honestly I have no other idea than stated in SDK documentation and you've already seen and mentioned it.

[wparad]

There are a lot more places to update if this is indeed true. See the message in the docs:

The sequence token is now ignored in PutLogEvents actions. PutLogEvents actions are always accepted and never return InvalidSequenceTokenException or DataAlreadyAcceptedException even if the sequence token is not valid. You can use parallel PutLogEvents actions on the same log stream.

Is the sequence token required by the library? What happens for the minimum supported AWSSDK.CloudWatchLogs version if the SequenceToken isn't specified?

Brilliant questions, thanks for highlighting them!

Regarding removing catches for mentioned exceptions - I saw it but really wasn't sure if the sequence token is the only source throwing them. Would suggest to remove them few versions later, but don't insist.

Regarding AWSSDK.CloudWatchLogs version that introduced this change - from changelog documentation it is 3.7.454.0 (2023-01-04 19:21 UTC).

Regarding necessity of sequence token - honestly I have no other idea than stated in SDK documentation and you've already seen and mentioned it.

So, I think the only thing I want to avoid is an in-between state. Assuming we continue with this PR, we can remove those exceptions as they are directly called out by the sequenceToken warning, and from experience they are only thrown when using an invalid sequence token.

My biggest concern is that right now, we support versions of the AWSSDK.CloudWatchLogs version 3.7.102.27, right now is set to be >= 3.7.1.

My recommendation here would be:

• Remove all the usages of sequenceToken
• Remove all the usages of the two exceptions that now will not be thrown
• Update the minimum required library version to 3.7.102.27
• Update the this library's package minor version number (to 4.3, I think)

[VadymLevkovskyi]

...

So, I think the only thing I want to avoid is an in-between state. Assuming we continue with this PR, we can remove those exceptions as they are directly called out by the sequenceToken warning, and from experience they are only thrown when using an invalid sequence token.

My biggest concern is that right now, we support versions of the AWSSDK.CloudWatchLogs version 3.7.102.27, right now is set to be >= 3.7.1.

My recommendation here would be:

• Remove all the usages of sequenceToken
• Remove all the usages of the two exceptions that now will not be thrown
• Update the minimum required library version to 3.7.102.27
• Update the this library's package minor version number (to 4.3, I think)

Done