axoniq / axon-server-api Goto Github PK

As off feature #969, Axon supports a split and merge of the Segments of a TrackingToken for a TrackingEventProcessor.
This functionality should also be available from Axon Server and as such this should be added to the PlatformOutboundInstruction message.

The TrackingToken, GetFirstTokenRequest, GetLastTokenRequest and GetTokenAtRequest, combined with the EventStore service, talk about the notion of a token. However from Axon Server's perspective, using the term offset would be better suited, as essentially that's what is being returned by Axon Server.

This issue covers various findings on the current API design. An implementor(s) may group these findings into subtasks.

If possible rename bidi stream messages to: Platform(Inbound/Outbound)(Command/Query/Control)Instruction. Use instruction_id i.o. message_id.

common.proto

• ErrorMessage -> rename location to source
• FlowControl -> deprecate client_id
• ErrorMessage -> introduce error_code as string

control.proto

• ClientIdentification -> rename client_id to component_instance_id, rename component_name to component_id
• SegmentStatus -> rename one_part_of to fraction

query.proto

• QueryProviderInbound -> rename QueryRequest query parameter to query_request
• QueryRequest -> rename message_identifier to message_id, rename client_id to component_instance_id, rename component_name to component_id
• QueryComplete -> remove message_id
• QueryResponse -> rename message_identifier to message_id, deprecate error_code (since it'll be part of ErrorMessage), check whether processing_instruction is needed
• SubscriptionQuery -> rename subscription_identifier to message_id, introduce SerializedType message as a copy of SerializedObject where 3 is reserved
• QueryUpdate -> rename message_identifier to message_id, rename client_id to component_instance_id and component_name to component_id
• QueryUpdateComplete -> rename client_id to component_instance_id and component_name to component_id, rename it to QueryUpdateCompleted
• QueryUpdateCompleteExceptionally -> rename client_id to component_instance_id and component_name to component_id, rename to QueryUpdateCompletedExceptionally, deprecate error_code
• SubscriptionQueryRequest -> reconsider current design - some field types could be adjusted
• SubscriptionQueryResponse -> remove message_identifier
• QuerySubscription -> rename query to query_name, rename result_name to result_type, rename client_id to component_instance_id and component_name to component_id

command.proto

• Command -> rename message_identifier to message_id, rename client_id to component_instance_id and component_name to component_id
• CommandResponse -> rename message_identifier to message_id, remove error_code, rename request_identifier to request_id
• CommandSubscription -> rename client_id to component_instance_id and component_name to component_id, remove message_id, rename command to command_name

event.proto

• Confirmation -> introduce Append(Event/Snapshot)Result
• TrackingToken -> rename token to position
• EventWithToken -> rename token to position
• QueryEventsResponse -> rename files_completed to historic_events_processed, introduce Void to common.proto and use it as type here
• RowResponse -> rename id_values to id_value and sort_values to sort_value
• ReadHighestSequenceNrResponse -> rename to_sequence_number to sequence_number
• GetEventsRequest -> rename tracking_token to position, rename client_id to component_instance_id and component_name to component_id, remove processor, change the type of PayloadDescription with newly introduced SerializedType and remove PayloadDescription
• Event -> rename message_identifier to message_id
• QueryValue -> rename to TypedValue and move to common.proto

The current control.proto contains Processing Instructions for actions like retrieving an EventProcessor it's status, calling a release/split/merge of a segment and starting and stopping one.

Each operation introduces a fairly simple change to the API, but a change nonetheless.
Ideally, we'd have a more generic API, which contains an instruction type and a 'serialized payload' of the processing instruction which is sent. That way, we're more future proof for follow up instruction's we'd want to add.