title: How can I gracefully migrate open Websocket connections after a deployment slot swap?
body: <p>In my web app when the user logs in to the app, their browser opens a Websocket to the server so that updates can be pushed down to the browser.</p>
  
  <p>It's an ASP.NET Core Web App (self-hosted) running in Azure App Services. I'd like to use Azure's <a href="https://docs.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing#swap-deployment-slots" rel="noreferrer">deployment slot swapping</a> feature to push code updates to production with zero downtime deployments.</p>
  
  <p>In the limited testing I've done, it looks like after a slot swap the Websocket connection stays open to the original slot the browser was connected to. (So if the browser's Websocket was connected to slot A, and we swapped slot A and B so that new connections go to slot B, the Websocket would still be open to the app running on slot A.)</p>
  
  <p>At some point the old slot will be taken offline, which will forcibly close any open Websockets. I would prefer to re-open the Websocket to the new slot as gracefully as possible and as soon as possible after the slot swap, so that if I update the Websocket-related code all clients will be running the new code as soon as possible.</p>
  
  <p>A sketch of how this might work:</p>
  
  <ol>
  <li>Slot swap takes place</li>
  <li>A notification is sent to the code running on the old slot</li>
  <li>Code running on the old slot pushes a Websocket message to reconnect</li>
  <li>On receiving the message, the browser opens a new Websocket connection (which will go to the new slot)</li>
  <li>When the connection succeeds, the browser closes the old Websocket</li>
  </ol>
  
  <p>Is there a better way to do it?</p>
  
  <p>How can the code running on the old slot know when it has been swapped?</p>
  
  <p>Is handling this gracefully even possible? Or are there always going to be a bunch of race conditions?</p>