GLFW_CONTEXT_ROBUSTNESS window attribute

To understand what, exactly, the GLFW_CONTEXT_ROBUSTNESS window attribute is all about, I studied this document:
https://www.opengl.org/registry/specs/ARB/robustness.txt
So if I use GLFW_LOSE_CONTEXT_ON_RESET, it means that to recover from a graphics reset, I have to destroy the OpenGL context and create a new one. Looking at the GLFW documentation, I figure the only way would be to destroy the window and create a new one, which I imagine could trigger inappropriate visual effects because some operating systems make it look cool when a window appears and when a window is closed. Could GLFW have a function that destroys the OpenGL context associated with a window and creates a new OpenGL context for the window, without ever destroying the window? I am sorry if I seem overly pedantic; my working assumption is that the GLFW_CONTEXT_ROBUSTNESS window attribute should not exist unless people really care what can happen in case of a graphics reset.

My understanding is that you don’t need to re-create the context on reset, you simply need to recreate all state - i.e. your OpenGL context is now back in the state it was after window creation. So you don’t need a new GLFW function, you just need to check for reset status with glGetGraphicsResetStatus and then re-initialize your graphic state (see the link for more).

That is not what I gather from this part, under the heading of “Issues”:

8. How should the application react to a reset context event?

   RESOLVED: For this extension, the application is expected to query
   the reset status until NO_ERROR is returned. If a reset is encountered,
   at least one *RESET* status will be returned. Once NO_ERROR is
   encountered, the application can safely destroy the old context and
   create a new one.

   After a reset event, apps should not use a context for any purpose
   other than determining its reset status, and then destroying it. If a
   context receives a reset event, all other contexts in its share group
   will also receive reset events, and should be destroyed and
   recreated.

   Apps should be cautious in interpreting the GUILTY and INNOCENT reset
   statuses. These are guidelines to the immediate cause of a reset, but
   not guarantees of the ultimate cause.

You’re right - re-reading the documentation they require a context to be re-created. I recommend posting a feature request to the issues on github, detailing the issue along why your applications requirements so that a priority can be set.

For now as a work around I suggest using GLFW_NO_RESET_NOTIFICATION for when you do not wish to display inappropriate visual effects, those drivers following the guidance will keep context state. For cases where you want to process the notification yourself, you can re-create the window as you mention.