mjhjmtu

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

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.