Edit Event Data
For Flux users, for an instance of a workflow getting executed in Flux runtime, there is a possibility that one or more tasks may fail/error/sideline based on wrongly submitted event data from either external event or one of the dependent events from previously dependent completed tasks because of a possible business logic error in dependent completed tasks. In such cases, Flux being a directed acyclic graph (DAG), completed states/tasks cannot be re-executed for a given workflow instance.
To solve this problem, if a Flux Client/User can update such corrupted event data, the sidelined/errored states can be submitted again for execution to Flux runtime.
Consider an instance of a Flux workflow defined in Figure 1 [we will refer to this workflow as WF subsequently in this document]. In WF, tasks T1 and T4 are completed. However tasks T2 and T5 are errored and sidelined respectively, possibly but not necessarily because of event data submitted E1 and E4 as output event from T1 and T4 are not as expected by tasks T2 and T5. In such scenario, making dependent events editable for sidelined/errored tasks allows the user to re-execute the task with new event data submitted via an api exposed through Flux Client.
Only triggered events with at least one of the next/immediate dependent state(s) in errored/sidelined/initialized state and none of these states in running state, in this case E1, are eligible for update of event data. There is only one state in Errored/Sidelined state dependent on input Event : In case of Event E4 which is a dependency for tasks T5, edit of event E4 data will be allowed only if task T5 is not in [Un-sidelined/Running/Completed] state.
In general, in case of 2 or more immediate states/tasks dependent on an Event, behavior defined in following table holds true. Edit Allowed - A - if at least one immediate task dependent on input event is in the state defined in row/column Edit Not Allowed - NA
With this provision, Flux Client or any external http call will be able to call an api to edit event data. This API will allow or decline event data edit based on condition/query as defined in the table above. If event data is edited/updated in storage, an audit entry will be added about the update of event data with its corresponding state Machine Id and event Name logged in audit record. However, for this release, since Event Data is updated, no data from history will be persisted in the storage, it will overwrite it. We will have a provision to store historical Event Data as well in a separate effort in future.
This layer also takes care of business logic for update event i.e. “Only triggered events with at least one of the next/immediate dependent state(s) in errored/sidelined/initialized state and none of these states in running state are eligible for update of event data.”
Post Api : /api/machines/{machineId}/context/eventupdate
public Response updateEvent(@PathParam("machineId") String machineId, EventData eventData)
HttpClient for an API created in step 2 in Flux Client Runtime Library with an optional eventSource parameter
void submitEventUpdate(String name, Object data, String correlationId, String eventSource)
This can be used by Flux clients to call the updateEvent API.
Sample POST request:
URL - http://{elb}/api/machines/{stateMachineId}/context/eventupdate
POST Request Body for EventData -
{"name" : "com.flipkart.flux.examples.benchmark.EventTypeInteger0",
"type" : "EventType",
"data" : "{\"value\":65}",
"eventSource" : "external"}