HangfireIO/Hangfire · error · JobLoadException
Could not load the job. See inner exception for the details.
Error message
Could not load the job. See inner exception for the details.
What it means
JobLoadException is thrown by InvocationData.Deserialize when anything fails while reconstructing a Job from persisted data: resolving the type, finding the method, or deserializing arguments. The original exception is preserved as InnerException so the real cause is inspectable. It signals that the job record in storage is no longer compatible with the running code.
Source
Thrown at src/Hangfire.Core/Storage/InvocationData.cs:118
CachedDeserializeMethod(typeResolver, Type, Method, ParameterTypes, out var type, out var method);
object[] arguments;
if (Arguments != null && !Arguments.Equals("[]", StringComparison.Ordinal))
{
var argumentsArray = SerializationHelper.Deserialize<string[]>(Arguments);
arguments = DeserializeArguments(method, argumentsArray);
}
else
{
arguments = [];
}
return new Job(type, method, arguments, Queue);
}
catch (Exception ex) when (ex.IsCatchableExceptionType())
{
throw new JobLoadException("Could not load the job. See inner exception for the details.", ex);
}
}
public static InvocationData SerializeJob(Job job)
{
CachedSerializeMethod(
TypeHelper.CurrentTypeSerializer,
job.Type,
job.Method,
out var typeName,
out var methodName,
out var parameterTypes);
var arguments = job.Args.Count == 0
? "[]"
: SerializationHelper.Serialize(SerializeArguments(job.Method, job.Args));
return new InvocationData(typeName, methodName, parameterTypes, arguments, job.Queue);View on GitHub (pinned to c236dd0f93)
Solutions
- Inspect the InnerException (and its message/stack trace) to identify the missing type, method, or argument.
- Restore or alias the renamed/removed method, or delete the orphaned job records from storage (e.g. via the dashboard or a SET deletion).
- Keep job methods stable and consider a compatibility shim/redirect when renaming; version job assemblies carefully.
- Ensure serialization settings (e.g. TypeNameHandling) match between enqueue and dequeue processes.
Example fix
// before: method renamed after jobs enqueued
public void ProcessOrder(Guid id) { ... } // renamed to ProcessOrderAsync
// after: keep a forwarding overload during migration
public void ProcessOrder(Guid id) => ProcessOrderAsync(id).GetAwaiter().GetResult();
public async Task ProcessOrderAsync(Guid id) { ... } Defensive patterns
Strategy: try-catch
Try / catch
try
{
var job = invocationData.Deserialize();
// use job
}
catch (JobLoadException ex)
{
logger.Error(ex, "Failed to load job {JobId}; inner: {Inner}", jobId, ex.InnerException?.Message);
await storage.DeleteJobOrMarkFailed(jobId);
} Prevention
- Never rename or delete a job method without deleting/migrating queued jobs first.
- Keep job method signatures stable; ship forwarding overloads when renaming.
- Use the same serialization settings and assembly versions on enqueue and worker sides.
- Monitor for JobLoadException in logs to catch deployment drift early.
When it happens
Trigger: Calling InvocationData.Deserialize() (directly or via storage APIs like MonitoringApi.JobDetails / StateMachine that load a job) where the stored Type/Method/ParameterTypes/Arguments cannot be mapped back to live code.
Common situations: Renaming or deleting a job method after jobs were enqueued; changing a method signature or parameter types; assembly renaming or version bump that breaks Type.GetType resolution; corrupted or hand-edited job arguments in storage; switching JSON serialization settings.
Related errors
- Background job creation failed. See inner exception for deta
- Output parameters are not supported: there is no guarantee t
- Parameters, passed by reference, are not supported: there is
- Anonymous functions, delegates and lambda expressions aren't
- exception
AI-assisted analysis of HangfireIO/Hangfire@c236dd0f93 (2026-08-13).
Data as JSON: /api/errors/2cf4520b492f259b.
Report an issue: GitHub.