It also seems to get stuck if I'm deleting a secondary index that's in construction.
I think this is because we query the status for the known secondary indexes explicitly:

"Nothing bad - Could not fetch secondary indexes statuses" cluster-min.js:2815
Object { name: "RqlRuntimeError", msg: "Index `Cancelled National Stock Number` was not found on table `nsntest.nsnnumbers`.", frames: Array[3], message: "Index `Cancelled National Stock Number` was not found on table `nsntest.nsnnumbers` in:
r.db("nsntest").table("nsnnumbers").indexStatus(r.args(["Cancelled National Stock Number", "NIIN Status Code", "Replacement National Stock Number"])).pluck("index", "ready", "blocks_processed", "blocks_total").merge(function(var_1469) { return {id: var_1469("index"), db: "nsntest", table: "nsnnumbers"}; })
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^      

We should probably just call indexStatus() without any arguments.

A third problem: After reloading the page, a secondary index that's in the "Building" stage is now shown as being in the "Started" stage. I'm not sure if we can currently distinguish between them from the indexStatus output. There's two things we could do:

1. expand indexStatus(), this is probably the better solution
2. make the web UI assume that an index is in the 'building' stage if the index already exists when loading the page. If an index appears later it's probably fair to assume it's in the started stage at first.

I think this might have been broken by changes done for the jobs table, since I believe indexes in the building stage weren't previously reporting the blocks_processed/blocks_total fields in indexStatus(), but now they do.

Edit: See #3726

In CR 2564