TIL: Five or more lessons I learned after working with Hangfire and OrmLite
13 Dec 2022 #todayilearned #csharp #showdevThis post is part of my Advent of Code 2022.
These days I finished another internal project while working with one of my clients. I worked to connect a Property Management System with a third-party Point of Sales. I had to work with Hangfire and OrmLite. I used Hangfire to replace ASP.NET BackgroundServices. Today I want to share some of the technical things I learned along the way.
1. Hangfire lazy-loads configurations
Hangfire lazy loads configurations. We have to retrieve services from the ASP.NET Core dependencies container instead of using static alternatives.
I faced this issue after trying to run Hangfire in non-development environments without registering the Hangfire dashboard. This was the exception message I got: “JobStorage.Current property value has not been initialized.” When registering the Dashboard, Hangfire loads some of those configurations. That’s why “it worked on my machine.”
These two issues in Hangfire GitHub repo helped me to find this out: issue #1991 and issue #1967.
This was the fix I found in those two issues:
using Hangfire;
using MyCoolProjectWithHangfire.Jobs;
using Microsoft.Extensions.Options;
namespace MyCoolProjectWithHangfire;
public static class WebApplicationExtensions
{
public static void ConfigureRecurringJobs(this WebApplication app)
{
// Before, using the static version:
//
// RecurringJob.AddOrUpdate<MyCoolJob>(
// MyCoolJob.JobId,
// x => x.DoSomethingAsync());
// RecurringJob.Trigger(MyCoolJob.JobId);
// After:
//
var recurringJobManager = app.Services.GetRequiredService<IRecurringJobManager>();
// ^^^^^
recurringJobManager.AddOrUpdate<MyCoolJob>(
MyCoolJob.JobId,
x => x.DoSomethingAsync());
recurringJobManager.Trigger(MyCoolJob.JobId);
}
}
2. Hangfire Dashboard in non-Local environments
By default, Hangfire only shows the Dashboard for local requests. A coworker pointed that out. It’s in plain sight in the Hangfire Dashboard documentation. Arrrggg!
To make it work in other non-local environments, we need an authorization filter. Like this,
public class AllowAnyoneAuthorizationFilter : IDashboardAuthorizationFilter
{
public bool Authorize(DashboardContext context)
{
// Everyone is more than welcome...
return true;
}
}
And we add it when registering the Dashboard into the dependencies container. Like this,
app.UseHangfireDashboard("/hangfire", new DashboardOptions
{
Authorization = new [] { new AllowAnyoneAuthorizationFilter() }
});
3. InMemory-Hangfire SucceededJobs method
For the In-Memory Hangfire implementation, the SucceededJobs() method from the monitoring API returns jobs from most recent to oldest. There’s no need for pagination. Look at the Reverse() method in the SucceededJobs() source code.
I had to find out why an ASP.NET health check was only working the first time. It turned out that the code was paginating the successful jobs, always looking for the oldest successful jobs. Like this,
public class HangfireSucceededJobsHealthCheck : IHealthCheck
{
private const int CheckLastJobsCount = 10;
private readonly TimeSpan _period;
public HangfireSucceededJobsHealthCheck(TimeSpan period)
{
_period = period;
}
public Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)
{
var isHealthy = true;
var monitoringApi = JobStorage.Current.GetMonitoringApi();
// Before:
// It used pagination to bring the oldest 10 jobs
//
// var succeededCount = (int)monitoringApi.SucceededListCount();
// var succeededJobs = monitoringApi.SucceededJobs(succeededCount - CheckLastJobsCount, CheckLastJobsCount);
// ^^^^^
// After:
// SucceededJobs returns jobs from newest to oldest
var succeededJobs = monitoringApi.SucceededJobs(0, CheckLastJobsCount);
// ^^^^^
var successJobsCount = succeededJobs.Count(x => x.Value.SucceededAt.HasValue
&& x.Value.SucceededAt > DateTime.UtcNow - period);
var result = successJobsCount > 0
? HealthCheckResult.Healthy("Yay! We have succeeded jobs.")
: new HealthCheckResult(
context.Registration.FailureStatus, "Nein! We don't have succeeded jobs.");
return Task.FromResult(result);
}
}
This is so confusing that there’s an issue on the Hangfire repo asking for clarification. Not all storage implementations return successful jobs in reverse order. Arrrggg!
4. Prevent Concurrent execution of Hangfire jobs
Hangfire has an attribute to prevent the concurrent execution of the same job: DisableConcurrentExecutionAttribute. Source.
[DisableConcurrentExecution(timeoutInSeconds: 60)]
// ^^^^^
public class MyCoolJob
{
public async Task DoSomethingAsync()
{
// Beep, beep, boop...
}
}
Even we can change the resource being locked to avoid executing jobs with the same parameters. For example, we can run only one job per client simultaneously, like this,
public class MyCoolJob
{
[DisableConcurrentExecution("clientId:{0}", 60)]
// ^^^^^
public async Task DoSomethingAsync(int clientId)
{
// Beep, beep, boop...
}
}
5. OrmLite IgnoreOnUpdate, SqlScalar, and CreateIndex
OrmLite has a [IgnoreOnUpdate] attribute. I found this attribute when reading OrmLite source code. When using SaveAsync(), OrmLite omits properties marked with this attribute when generating the SQL statement. Source.
OrmLite QueryFirst() method requires an explicit transaction as a parameter. Unlike SqlScalar() which uses the same transaction from the input database connection. Source. I learned this because I had a DoesIndexExists() method inside a database migration and it failed with the message “ExecuteReader requires the command to have a transaction…“ This is what I had to change,
private static bool DoesIndexExist<T>(IDbConnection connection, string tableName, string indexName)
{
var doesIndexExistSql = @$"
SELECT CASE WHEN EXISTS (
SELECT * FROM sys.indexes
WHERE name = '{indexName}'
AND object_id = OBJECT_ID('{tableName}')
) THEN 1 ELSE 0 END";
// Before:
// return connection.QueryFirst<bool>(isIndexExistsSql);
// ^^^^^
// Exception: ExecuteReader requires the command to have a transaction...
// After:
var result = connection.SqlScalar<int>(doesIndexExistSql);
// ^^^^^
return result > 0;
}
Again, by looking at OrmLite source code, the CreateIndex() method, by default, creates indexes with names like: idx_TableName_FieldName. Then we can omit the index name parameter when working with this method. Source
Voilà! That’s what I learned from this project. This gave me the idea to stop to reflect on what I learned from every project I work on. I really enjoyed figuring out the issue with the health check. It made me read the source code of the In-memory storage for Hangfire.
For more content, check how I use the IgnoreOnUpdate attribute to automatically insert and update audit fields with OrmLite, how to pass a DataTable as a parameter with OrmLite and how to replace BackgroundServices with a lite Hangfire.
Happy coding!