The Case of the Finicky Form

Recently we ran into a situation where the login form for an application we supported would fail to launch. This surprised us as this application has been running for over 6 years with no changes to the login form or the code that would call it. However, since we had made some changes (in a different module) we made the only reasonable conclusion: something we did was responsible for this problem.

The area of the application we updated manages the service that checks for updates online. As with many of our applications, this system would connect to a dedicated server for application updates, account validation, and system messages. It does this prior to allowing the user to see the login dialog, which is necessary in case the account was disabled for some reason.

For this application we made use of the Socket Server connector. In a short while, the physical server will be virtualized and relocated to a new network. In anticipation of this change, we updated the system to support both servers using a form of fall-over logic:

Connect to primary server
If Successful then
   // Process server requests
end else
   Connect to secondary server
   If Successful then
      // Process server requests
   end else
      // Notify user that server is unavailable
   end
end

The logic was simple enough. However, when we disabled the primary server to test our fall-over strategy we began to see a pattern. While the connection to the secondary server was successful, the login dialog would fail to launch. Before too long we were reminded of a particular behavior of OpenInsight that is often forgotten: Forms do not launch when there is an active error status. In our case, the active error status occurred when the connection to the primary server failed (SOCK102 – Unable to resolve host DNS entry.) Our oversight was assuming that the subsequent and successful attempt to connect to the secondary server would have cleared any error flags. Not so…

The fix was thankfully very simple – we clear all error flags using Set_Status(0) upon failure to connect with the Socket Server. This enabled our login form to launch successfully every time. This little exercise also brought back to mind a question that comes up from time to time among our developers: should error flags remain set until explicitly cleared or should they clear themselves? Getting caught like this reaffirmed our opinion that error flags should clear themselves or at the very least not be allowed to unnecessary prevent other commands to fail. It should be the responsibility of the developer to properly check error flags and then decide if any action is required. If not, then let the system move forward unabated. Being forced to clear error flags is a bit of a nuisance. But perhaps this is a debate for the online forums. 🙂