Spec gives bad advice on generating transaction IDs

[tulir]

In https://spec.matrix.org/v1.9/client-server-api/#transaction-identifiers the spec says (emphasis mine)

From the client perspective, after the request has finished, the {txnId} value should be changed by for the next request (how is not specified; a monotonically increasing integer is recommended).

Recently two developers have encountered issues with transaction IDs ([1], [2]). In both cases, it turned out they had followed the recommendation from the spec and used a plain monotonically increasing integer as the transaction ID. Counting from 0 means there are conflicts whenever the counter resets, and persisting counters is error-prone. The first case had a persistence bug, the second case was creating a new access token on each startup, but MSC3970 broke that by changing transaction ID scope from access token to device ID.

Something like concatenating the current timestamp with a monotonically increasing integer would be a much safer recommendation.

[TheArcaneBrony]

Personally using version 4 GUIDs as tnxIds, I'd say anything that can be reasonably guaranteed to be unique would be a fairly safe recommendation.
Perhaps alternatives could be listed in the spec?

[Johennes]

For reference:

• matrix-js-sdk uses a combination of timestamps and a monotonically increasing integer: https://github.com/matrix-org/matrix-js-sdk/blob/3f5a994a2489f6714bf50ca4da09a2fc63a9987b/src/client.ts#L7870
• matrix-rust-sdk (via ruma) uses v4 UUIDs: https://github.com/ruma/ruma/blob/6347f547c194463a92fbb7cf97d217a2d36b92f7/crates/ruma-common/src/identifiers/transaction_id.rs#L23