Beginning in early August, users of Matador Jobs who also use the Bullhorn Indeed Syndication tool to post their jobs to Indeed began seeing things work not quite as expected. We discussed this issue in a past blog post, providing guidance and work-around procedures while we investigated. Today, we can confirm that we’ve developed a solution that, once installed, will end this frustration for our users moving forward.
Recap: Bullhorn’s Indeed Syndication
When users of Bullhorn are ready to begin marketing a new job (role, vacancy), they use the Bullhorn ATS publishing process. During the publishing process, users are presented with a checkbox that allows them to also publish the job to Indeed.
As we understand it, when also published to Indeed, the job data is provided to Indeed via a Bullhorn-generated XML file that Indeed uses to import the user’s Bullhorn job data onto their platform.
Users of Matador Jobs have been using this feature of Bullhorn’s for some time without issue, but in the summer, this changed. Suddenly, newly published jobs would show up in the Indeed dashboard as “expired” even though they were brand new, active opportunities.
A Race Condition
Our theory as to the cause of these issues is that starting at some point in July 2020 Indeed or Bullhorn changed how it handled data from this feed resulting in a race condition.
A race condition is a type of computer bug that arises when a computer program, in order to work as intended, depends on two or more steps in a sequence to occur in order, and they do not.
We believe that one (or more) of the following changes occurred to make an existing race condition more likely or create a new race condition:
- Bullhorn, may have previously updated it feed on a schedule, but increased the rate of which the feed was been updated and/or provided the feed real-time, making an existing race condition bug more likely.
- Indeed, may have previously accessed the feed on a schedule, but increased the rate of which it updated its data from the feed and/or began accessing the feed in real time, making an existing race condition bug more likely.
- Indeed, which may have previously not validated the feed, began sending a “bot” to access the jobs pages, and sometimes did not find them as Matador hadn’t synced by the time the bot visited, creating a new step in a sequence creating or making more likely a race condition bug.
If we were to guess, we believe condition 3 is most likely cause, but we want to stress that this is only a guess.
Let’s recap for a sec how Matador Jobs works, and always has, since our launch in January 2018: Matador sets up a scheduled task called a “cron” that triggers a sync to Bullhorn automatically every 60 minutes. Any jobs newly published, or published jobs updated, closed, deleted, or unpublished in that time frame are added or removed from your site at that time. We do this once per hour because an API to Bullhorn is resource-intensive and we like to keep Matador as light as possible so it can run on all kinds of web hosts.
So, our system always had a short delay between publishing on Bullhorn and syncing to the site, so our theory is that sometime in summer, a change occurred where this gap in time became a problem. The updated race condition required Matador’s sync to complete faster than it was happening naturally.
Complex Problems Take Time to Solve
We at Matador worked with our partners at Bullhorn and, through them, spoke with representatives at Indeed, during the late summer and fall to try and figure this out. Progress was slow. While this was happening, our users would attempt similar connections, and these support requests usually ended in the various parties confirming to the user that their platform is not the cause of this issue.
This was/in, in fact true; if the issue was the result of a race condition between three separate pieces of software, all single parts of the puzzle could’ve been in perfect working order while, as a whole, the combination was not.
We assure you, our users, that despite the delays, we were proactive during this frustrating time. We identified alternate solutions and helped many of you set up these alternates. Our goal was always, however, to provide a solution, either ourselves, or by encouraging one of our partners to deploy one.
And, well, we think we found one.
Winning The Race
We found inspiration for a solution in the Bullhorn Open Source Career portal. The OSCP gets its data on demand via a javascript request, unlike Matador which syncs data locally on a schedule. Matador syncs data for both its speed and data uptime benefits, but the fact that OSCP was never a victim of this race condition meant giving it a closer look.
Our solution needed to preserve the cached local copy benefits of the Matador platform while being able to access data from Bullhorn on demand while also not consuming too many server resources that would result in a user being charged more for hosting or losing performance.
For the Matador Jobs 3.6.4 release, we’ve developed a way for Matador Jobs to request a job on demand when a certain URL structure is accessed by a visitor (human or bot). We applied this behavior to the unique URL structure we introduced in March for the Matador 3.6.0 release specifically for the Bullhorn Indeed Syndication tool.
Since 3.6.0, if your site has a jobs page at https://your-site.com/jobs and a job URL that follows the pattern like https://your-site.com/jobs/a-sample-job-page, an alternate URL scheme is available where the Bullhorn ID of the job can replace the last part. When a job is found with that ID, a redirect will be made to the proper URL. So https://your-side.com/jobs/1234 for Bullhorn job ID 1234 will automatically redirect to the job page at https://your-site.com/jobs/a-sample-job-page or to a “not found” error if a job with that ID does not exist.
With 3.6.4, if the job ID does not exist on your site, instead of telling the visitor (or bot) that the job is “not found”, Matador will now delay the response to the visitor while, in the background, it will make a call to Bullhorn to see if a job with that ID is available. If it is, Matador will import the job immediately, end the delay, and allow the visitor to visit the newly imported job’s page.
And that is how we will win the race, by putting up a roadblock when we think we are behind, and give ourselves time to catch up.
Important Note: Republish “Expired” Indeed Jobs
Please note: if you are a user of Bullhorn’s Indeed Syndication tool experiencing “expired” jobs on Indeed that are open and accepting application on Bullhorn and Matador, note that the upgrade to 3.6.4 will only prevent this issue moving forward and not retroactively fix these affected jobs.
To fix these affected jobs, go into Bullhorn and publish the affected jobs again. This will place the jobs back to the top of the Bullhorn Indeed Syndication XML feed and trigger Indeed to recheck them. This is a one-time task and only required for jobs Indeed shows as “expired” that are, in fact, not.
Final Notes From The Winner’s Podium: Release Timeline and Thank You
As of yesterday, we had three users beta testing this feature and with no reported issues, will begin releasing 3.6.4 immediately. Please log into your WordPress site and trigger the plugin update as soon as possible. If you are unable to update, make sure your support and updates subscription is active and you’ve input the license key into your Matador settings.
Thank you for your patience, understanding, and support as we’ve worked with our partners at Bullhorn and with contacts at Indeed to figure this out. We know some of you have been very frustrated and we appreciate your patience and we are so glad to be able to finally provide you a solution!
As always, let us know if you have further feedback, issue reports, or feature requests, as we are here for you, our users, and always committed to making Matador the best it can be for you!
You must be logged in to post a comment.