tzulitai opened a new pull request #177: URL: https://github.com/apache/flink-statefun/pull/177
This PR extends the current remote invocation request-reply protocol to allow functions to reply with a `IncompleteInvocationContext` response. The end goal for this protocol extension is to allow state specifications to be declared in the functions (via the language SDKs), instead of being declared statically in the module YAML definition files. ## Extended protocol with the new `IncompleteInvocationContext` response type Below is an explanation of how the new protocol works: 1. On startup, the StateFun worker processes will not have any knowledge of remote function states, and therefore do not register / attempt to access any Flink state on their behalf. 2. On the first remote invocation, the invocation request would not carry any state values. 3. Upon receiving the invocation request, the functions may decide to respond with a `IncompleteInvocationContext` or the usual `InvocationResponse` as before. If the functions find that the invocation request has missing state values (after matching the provided state names with the declared states in the functions), then it should respond with the new `IncompleteInvocationContext` response type. 4. When the StateFun workers receive an `IncompleteInvocationContext`, it dynamically registers Flink state for the indicated missing states, and then re-sends the original invocation batch now "patched" with all required states. 5. All following invocation requests will be attached with all the required states. 6. The same state specification discovery process from (3) to (5) applies when a function upgrades itself and declares new state, without restarting the StateFun workers. ## Brief change log - 923914b Changes the Protobuf messages definition file to have the new `IncompleteInvocationContext` response type - f75d7dd to 86aed63 does a few things surrounding `PersistedRemoteFunctionValues`. Most importantly, a new `registerStates` method is added to the class to support registering new `PersistedValue`s dynamically based on `IncompleteInvocationContext` responses from functions. Secondly, mark the original eager state spec (coming from module YAMLs) constructor as deprecated, as this will no longer be supported before the next release. Finally, a UT `PersistedRemoteFunctionValuesTest` is added to cover the user contracts of the class. - 2db4ad1 Actual implementation of the extended protocol in the `RequestReplyFunction` dispatching logic. ## Testing the change - User contracts of the adapted `PersistedRemoteFunctionValues` class is covered in the new UT `PersistedRemoteFunctionValuesTest` - A new UT `retryBatchOnIncompleteInvocationContextResponse` has been added to `RequestReplyFunctionTest` to verify that the `RequestReplyFunction` re-sends the original batch with patched states on `IncompleteInvocationContext` responses. ## Upgrading existing SDKs After merging this PR to `master`, existing language SDKs may begin to be upgraded to implement the new extended protocol. A separate PR will be provided for updating the Python SDK, as a "reference" for upgrading other language SDKs. ## Backwards compatibility for existing SDKs For the time being (before the next release), old SDKs yet to be updated would still work as is against `master`, since eagerly declaring state specifications via the module YAML definition files (format versions <= `2.0`) will still be temporarily supported in the snapshot `master` branch. With the next major release (version `2.3.0`), module YAML format versions <= `2.0` will no longer be supported, and therefore old SDKs that are not updated will cease to work with StateFun 2.3.0. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
