For a single transaction, we found:
Event1 ID: #12209ab878360cd6f8272ffdf92d84775b5a33579e4d3bad234b6cb9eda1b02127ec:0
Event2 ID: #12209ab878360cd6f8272ffdf92d84775b5a33579e4d3bad234b6cb9eda1b02127ec:10
So the suffix of the first event is 0 while the suffix of the second event is 10. Are suffixes of events within a transaction not guaranteed to be sequential? Or is this because there could be other events between suffix 0 and suffix 10 which are not visible to the Party?
Precisely.
No, because of the reason you mentioned above, this is a guarantee that cannot be given when a given party consumes a stream of transactions.
Understood, but can I confirm all events within a tx will always have suffixes starting at 0 and increasing by 1 (irrespective of which of these will be visible to who)?
Is there some reason in particular why you would want this guarantee?
We need to know the max length to expect for a eventId as part of an integration with a data warehouse. The txId is fixed at 68 characters, and assuming a max of 999 events in a tx, we could assume a max length of 72 characters (including the colon “:” character).
But this derivation doesn’t hold true if the suffix is not generated in a sequence, eg if the first event has suffix 0, second has a suffix of 1000, then it becomes very difficult for us to integrate with the data warehouse.
An event_id must be a valid LedgerString (doc) which is described here as follows:
LedgerStrings are strings with length <= 256 that match the regexp
[A-Za-z0-9#:\-_/ ]+.
While I’m not 100% sure you can get any guarantee with regards to the format of event IDs, you do have a guarantee that their size will never exceed 256 characters in the restricted range described above.
Does that help?
It has been brought to my attention that the documentation is inaccurate and there’s an off-by-one error. The limit is 255 characters. We’re about to merge a fix for this.