Platform Event ReplayId - metadata says it is a String of length 1000 but evidence shows it as an integer

Question

Related post on uniqueness of replayIds

Using Workbench to examine metadata for the OOTB field ReplayId on any Platform Event SObject (one that ends in __e) shows:

• bytelength: 3000
• length: 1000
• type: String

Now, evidence shows (and Platform Event documentation and related StreamingAPI documentation) this value to be an integer. Even the JSON example in the StreamingAPI shows it as a number:

{
 "clientId":"a1ps4wpe52qytvcvbsko09tapc",
 "data":{
    "event":{
            "createdDate":"2016-03-29T19:05:28.334Z",
            "replayId":55
        },
    "payload":"This is a message."
    },
 "channel":"/u/TestStreaming"
}

Further cementing the evidence that Replayid is an integer, doing a metadata describe on EventBusSubcriber, the fields Tip and Position are both of type int with 9 digit precision. These two fields define the relative points in the stream between last event published versus last event consumed.

So, should I care? Or is an assumption of integers good enough?

Rationale for asking ... I was planning on a solution wherein I backed up incoming platform events to Sobjects by publishing out another platform event (which is guaranteed to publish even if the initial consuming transaction blows up on a Limits exception). Think of this a fallback backup solution.

The backup SObject had a uniquekey defined as the concatenation of the initial xxx__e sobjectType + Replayid. This strategy works fine if replayids are numbers as the unique key will be < 255 chars in length. But if Replayids can be 1000 characters long, I need to rethink things.

Side note ..to date in our org, Replayids have incremented up to about 1,000,000 for the most active xxx__e platform events

Answer 1

So, should I care? Or is an assumption of integers good enough?

In my opinion, as long as it's documented to be numeric, I would go ahead and utilize this as number.

While this is still not clear why the describe would show a different result, but in any case if there's a scenario where there seems to be a discrepancy, I would reach out to Salesforce to make sure the implementation based on documentation will not fail.

Thinking it from a different perspective, if I use a Java Client using CometD to subscribe to an Event, I will always pass an numeric replayId instead of a String value to make sure that I successfully retrieve all replay ids after the value that I am passing.