Deploy fix for Updating Bridges Bug

Another WIP to solve the #249 bug.

Calling close(stop) to indicate the channel is closing in getResourceStreamHandleris causing a panic because the channel is already closed so I guess having the signalling channel here isn't helping/isn't in the right place. I'm wondering if we improved upon the problem by removing the select that was trying to send the diff in getResourceStreamHandler but the problem in propagateUpdate remains. Previously, I added a case to propogateUpdate so that if the channel was closing/closed, propagateUpdate wouldn't try to write to it. However, the signal wouldn't have been received if there was a panic each time (which again, wouldn't be a problem unless it happens at the same time as the channel is unregistered). I'm not sure if adding close(ClosingSignal) to UnregisterChan could help? Or if there's another way we can indicate the channel is closing so we don't get blocked there.