How do I stop this thing?

If the user wants to stop a process that is running, why not just let them?

Let’s revisit the rollercoaster story. Under normal circumstances, once the carriages have left the station, they twist and turn, go upside down, chug up hills, race down hills and generally impart thrills aplenty. As a rider, you have no control over this. Once you are strapped in, you are in for the entire ride—all the way back to the station.

Now imagine that each rider has their own control to stop and get off at any time. If I am not enjoying the ride, I can simply press the red button, the ride stops, and I get off.

There are a few issues with doing that.

The first is getting the riders and carriages back to their starting state. The seat belts have to be released so that everyone can get out, and there needs to be a way for them to exit safely. This may be especially problematic if the carriages happen to be upside down when they stop.

Another issue is the state of the riders. They signed up for 100% thrills and received only a portion of that. They may need a refund or the chance to take a subsequent ride.

At this stage, let’s not push the analogy much further. How does this relate to stopping a script?

What could go wrong?

Many scripted processes apply changes to a set of records. Consider a process that queries an API for new data and imports it. The steps may be as follows:

1. Run the API query for recently created records.
2. Process each API record to check whether it has previously been processed.
3. For each unprocessed record, import the data into a holding table and pause as needed.
4. Import the parsed data into a live table.
5. Mark each holding-table record as complete.

Let’s say the user runs this API query and finds that importing into the holding table is taking some time. They decide to stop the process and get on with something else.

The holding-table data is now in a partially processed state. There are records from previous completed processes that have been parsed, imported and marked as complete. Depending on exactly when the process was stopped, there may also be unprocessed holding-table records—and perhaps a record that has been only partly imported.

There may be other issues in the live table if the process was stopped at a different point.

How do we fix this?

This partially processed state is caused by stopping a process midstream. To fix it, we need either to complete the processing or roll back the processing that has occurred.

In either case, we need to know exactly where the process got to before it was stopped.

For example, perhaps we logged how many records were returned by the API query and can compare that number with the number imported. If all records have been imported, we might check how many have been parsed. If all records have been parsed, we might check how many have been imported into the live table. Finally, we might check how many holding-table records have been marked as complete.

You may be starting to see how complicated this can become. The ultimate solution may be to prevent it from happening in the first place.

Let’s continue this tomorrow.