11.8 Kill the worker mid-run

Place another order, and kill the worker while it packs, within the ten seconds. Kill it, not stop it: Ctrl+C asks the worker to finish what it is running first, which is the point of stopping one.

pkill -9 -f Shopfront.Worker

The fulfilment's run says In progress in the console, and stays that way, because nothing is running it. Start the worker again. It does not pick the run up: the job was claimed and started, and a job that started is never started twice, since running it again might pack a parcel twice.

The hub sees to it instead. Every run in progress longer than its timeout is given up on, and in Development that is about a minute. The failure hook tells staff:

warn: Shopfront.Staff.LoggingStaffNotifier[0]
      For staff: Shopfront.Trains.FulfilOrder.IFulfilOrderTrain failed: Job was stuck InProgress beyond the configured stale in-progress timeout

Two settings decide when, and both are shortened in Development. DefaultJobTimeout, 20 minutes by default, is how long a job may run before the hub cancels it. StaleInProgressTimeout, an hour by default, is how long after that a run still in progress is failed. Shortening only the second changes nothing, because the hub waits for the first.

The run is Failed now, and its reason says why. A fulfilment has no manifest, so nothing retries it. A member of staff decides: open the run in the console and choose Re-queue, which runs it again with the input it was given, on whichever worker claims it.

SDK Reference

AddTraxWorker | ITrainExecutionService | Queued work | Job submission | Structuring your application | Host tracking

Next: 11.9 Test it