search

restatedev / sdk-java

Restate SDK for JVM Languages
https://restate.dev
MIT License
22 stars 4 forks source link

Does it makes sense to expose the service invocation id? #15

Closed slinkydeveloper closed 1 year ago

slinkydeveloper commented 2 years ago

During a couple of feedback sessions, we discussed the integration with other services, and the "idempotency key". Does it makes sense to expose the service invocation id, so the user can use it as idempotency key? This removes the need to generate a random uuid and persist it using side effects, and it has the plus of simplifying debuggability, as the user can correlate the service invocation with the external invocation.

We don't need to expose the service invocation id in a structured manner, but simply as an opaque value, e.g. String.

Related to https://github.com/restatedev/sdk-java-experiment/issues/17, in a sense that exposing the service invocation id removes the need in a lot of use cases for the random interface. Even better, the user could use the service invocation id as the seed for instantiating the Random.

igalshilman commented 2 years ago

Exposing the invocation id will help with a lot of cases like that indeed :+1: , even further replacing the invocation id to something like a ULID, or UUIDv7 would even takes us a step further for more advance conflict resolution (beyond idempotent key)