Hello all I've recently updated our local Galaxy instances to use a novel in-house job runner as part of a migration to a new VM platform. As far as I can determine the runner is able to run jobs without any issues, on all versions of Galaxy that I've tried (v15.10/v16.01/v16.04/release_16.10). However: when moving to release_16.10 I've noticed a minor issue with the UI, where the job state in the history no longer automatically switches from the grey "queued" state to the yellow "running" state - even though the logs indicate that the job status has changed internally. Refreshing the history correctly updates the job to the correct yellow "running" state (so it would seem that internally Galaxy knows that the job status has changed), and transitions between other states seem to happen automatically. Comparing my novel runner code with that for e.g. the drmaa runner , I can't see what might be missing from mine to cause this issue. I had wondered if it could be a problem with out of date Javascript in the UI somehow not detecting the job status change from "queued" to "running", but using the "local" job runner doesn't exhibit this behaviour. (The source code for the runner can be found here: https://github.com/pjbriggs/ansible-palfinder-galaxy/blob/jse-drop-add-prefi... It submits jobs to the cluster by "dropping" the scripts into a shared directory, which are then collected and executed by a separate process running on the cluster - with all communication done via files.) Can anyone suggest what might be happening to cause this issue? Many thanks Peter -- Peter Briggs peter.briggs@manchester.ac.uk Bioinformatics Core Facility University of Manchester B.1083 Michael Smith Bldg Tel: (0161) 2751482