Salsify is a multi-tenant SaaS product information exchange platform hosted in Heroku. We utilize delayed job extensively for long running tasks like import/export/search indexing/etc. One of the features we've grown to love about delayed job is its extensibility via plugins (see our other posts). Recently, an increasing number of job workers have been exceeding their dyno memory quota**, and consequently suffering serious performance degradation. While we are always working to improve our code performance, we thought it would be nice to have a mechanism for euthanizing workers that are unrecoverably exhausted. Enter the DelayedJob::YouthInAsiaPlugin.
I wanted to share a bit of information that we found interesting when writing active record migrations on tables leveraging STI (Single Table Inheritance). We came across a not so obvious gotcha with STI models re-defined in migration classes and wanted to explore our thought process while solving the subsequent problems.
Here at Salsify we follow a git flow branching model, so it is common for us each to work independently on feature branches while regularly merging to and from a shared develop branch. We also routinely push code to staging and production environments for internal review and release. The combination of our fast-paced development environment and extensive use of branching occasionally results in conflicts when landing new features. We recently encountered one of these conflicts (sequencing not code) in a pair of ActiveRecord migrations and found a workaround we thought might be useful to others. The following migration excerpts were written on two different branches: