I really don't see what this is supposed to protect against. If SwapBuffers actually fails in some rare scenario it is an indicator something else went wrong way earlier in code that wasn't caught properly. Recreating the device context in this situation is equivalent to sweeping the real problem under the rug. We don't even know if recreating the device context in this way can lead to other negative side effects. Device contexts don't only belong to windows but pbuffers as well, which this change completely ignores.

In all the years I have been debugging OpenGL applications I have never once seen SwapBuffers fail, and to be honest I wouldn't even know how to provoke such a failure without doing something obviously wrong with some other code. If you also can't provide more information about how to reproduce the issue that this change is supposed to solve we can't even test if this change actually makes things better and whether it introduces any other negative side effects in such a case.

For all we know what you observed could have just been the result of some undefined behaviour or data race introduced somewhere else in your code that you eventually fixed and thus can't reproduce any longer.

My application runs as a plugin to other software (digital audio workstations), so if what you're saying is true, it's possible that the other software was causing the problem and my tweak was just keeping my plugin chugging along anyway.

Because it prints an error, I wouldn't say it's sweeping anything under the rug, but rather adds an additional check & recovers gracefully from an error state in the field.