{"action":"opened","issue":{"url":"https://api.github.com/repos/cypress-io/cypress/issues/349","repository_url":"https://api.github.com/repos/cypress-io/cypress","labels_url":"https://api.github.com/repos/cypress-io/cypress/issues/349/labels{/name}","comments_url":"https://api.github.com/repos/cypress-io/cypress/issues/349/comments","events_url":"https://api.github.com/repos/cypress-io/cypress/issues/349/events","html_url":"https://github.com/cypress-io/cypress/issues/349","id":196160229,"number":349,"title":"Recover from renderer crashes","user":{"login":"brian-mann","id":1268976,"avatar_url":"https://avatars.githubusercontent.com/u/1268976?v=3","gravatar_id":"","url":"https://api.github.com/users/brian-mann","html_url":"https://github.com/brian-mann","followers_url":"https://api.github.com/users/brian-mann/followers","following_url":"https://api.github.com/users/brian-mann/following{/other_user}","gists_url":"https://api.github.com/users/brian-mann/gists{/gist_id}","starred_url":"https://api.github.com/users/brian-mann/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brian-mann/subscriptions","organizations_url":"https://api.github.com/users/brian-mann/orgs","repos_url":"https://api.github.com/users/brian-mann/repos","events_url":"https://api.github.com/users/brian-mann/events{/privacy}","received_events_url":"https://api.github.com/users/brian-mann/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-12-16T21:41:14Z","updated_at":"2016-12-16T21:41:14Z","closed_at":null,"body":"Related to #348.\r\n\r\nIt is actually possible for Cypress to implement strategies when the renderer (or browser process) crashes during a test run - something like `recoverFromRendererCrashes: true` by default.\r\n\r\nThere is already a mechanism for Cypress to \"reload\" mid-run, rebuild the state of every previous run test, skip over previously run tests, and continue with the next one in line.\r\n\r\nIn fact this is exactly what `cy.visit` already does under the hood.\r\n\r\nWe can utilize this same process upon a renderer / browser process crashing to continue on with the run.\r\n\r\nSo it may look something like this:\r\n\r\n```bash\r\n(Running Tests)\r\n\r\n✓ test 1 - foo\r\n✓ test 2 - bar\r\n✓ test 3 - baz\r\n\r\nOh noes the renderer process crashed... we will attempt to recover\r\n\r\n...Restarting tests at 'test 4 - quux'\r\n\r\n✓ test 4 - quux\r\n✓ test 5 - ipsum\r\n```\r\n\r\nTaking this a step further, we are starting to see several patterns emerge with how and why renderer processes crash - it is almost always related to extremely long test runs in a memory starved environment (such as Docker).\r\n\r\nIt may even be a good idea for us to always preemptively \"break up\" headless runs by spec file. \r\n\r\nIn other words, we could have an option like `restartBrowserBetweenSpecFiles: true` which would automatically kill the renderer process before moving on to a different spec file (but still rebuild the state of the UI correctly, and still have a single contiguous video recording). \r\n\r\nTo the user it would look like nothing is really different, but internally the renderer process would be killed and then restarted.\r\n\r\nThis would forcefully purge primed memory from the process, which could keep environments like `docker` from ever crashing to begin with.\r\n\r\n"}}
{"actor":{"display_login":"brian-mann"}}