Fixing 58 server bugs and warnings (Why so many?)

Along with the hundred styling changes and UI cleanup we are wrapping up, we also took the opportunity to fix around 58 different errors and warnings being reported by our server.

This might sound like a lot, so perhaps a little context is useful:

  • Kerika is built on top of Google Apps (at least, for now): we use Google’s OAuth service to sign up and sign in people, and we use Google Drive to share files within project teams.
  • A lot of errors show up as a result of this Google integration, only a fraction of which are solvable from our perspective:
    • Some errors relate to people from restricted Google Apps domains trying to use Kerika. This happens at least once a week — someone working at a company that has Google Apps for Business tries to sign up for Kerika, but fails because their Google Apps Administrator (typically, someone within their IT department) has prohibited any third-party apps from integrating with their Google Drive.
      This is an example of an unsolvable problem — we can’t override the existing protection that this company has set up (and nor would we want to!) so we are going to redirect users to an explanatory page that helps them understand the problem is not with Kerika.
    • Sometimes Google Apps has outages: when this happens, we can get a cascade of errors on our servers, because these outages are typically intermittent and inconsistent across our user base. Some folks experience problems, others don’t. We are trying to come up with a way to inform people about what’s happening, so they don’t think it’s Kerika that’s busted.
    • Sometimes Google burps: not have an outage, but experience a fleeting problem with uploading a file. We might get nothing back from Google than a generic “500 error: system not available”.
  • We have also had problems related to our use of Firefox for the Render Server: Firefox’s latest updates are sometimes less stable than previous ones, and in general Firefox is starting to have a really big footprint in terms of memory usage.
  • And, finally, we have had our own bugs, just like any other software developer. Some of these have been tricky to find, but as we find them, we squash them.