HangfireIO/Hangfire · error · ArgumentException

Context argument should be of type `AspNetCoreDashboardConte

Error message

Context argument should be of type `AspNetCoreDashboardContext`!

What it means

Hangfire's ASP.NET Core dashboard extension method GetHttpContext attempts to cast a DashboardContext down to the concrete AspNetCoreDashboardContext to reach the underlying HttpContext. When the supplied object is some other DashboardContext implementation (or a test double), the cast fails and an ArgumentException is thrown. This is a type-safety guard: the dashboard routing/middleware in ASP.NET Core always produces an AspNetCoreDashboardContext, so hitting this means custom code or a custom IDashboardAuthorizationFilter/middleware fed the wrong concrete type.

Source

Thrown at src/Hangfire.AspNetCore/Dashboard/AspNetCoreDashboardContextExtensions.cs:31

// You should have received a copy of the GNU Lesser General Public 
// License along with Hangfire. If not, see <http://www.gnu.org/licenses/>.

using System;
using Hangfire.Annotations;
using Microsoft.AspNetCore.Http;

namespace Hangfire.Dashboard
{
    public static class AspNetCoreDashboardContextExtensions
    {
        public static HttpContext GetHttpContext([NotNull] this DashboardContext context)
        {
            if (context == null) throw new ArgumentNullException(nameof(context));

            var aspNetCoreContext = context as AspNetCoreDashboardContext;
            if (aspNetCoreContext == null)
            {
                throw new ArgumentException($"Context argument should be of type `{nameof(AspNetCoreDashboardContext)}`!", nameof(context));
            }

            return aspNetCoreContext.HttpContext;
        }
    }
}

View on GitHub (pinned to c236dd0f93)

Solutions

1. Ensure the code path runs inside the real ASP.NET Core dashboard middleware, which constructs AspNetCoreDashboardContext automatically.
2. If authoring a custom filter/middleware, accept the base DashboardContext only where HttpContext is not needed, or obtain HttpContext via IHttpContextAccessor instead of GetHttpContext().
3. In tests, construct an AspNetCoreDashboardContext (it wraps an HttpContext) rather than the base DashboardContext.
4. If you maintain a custom DashboardContext subclass, expose the HttpContext through AspNetCoreDashboardContext or stop relying on GetHttpContext().

Example fix

// before
var http = context.GetHttpContext(); // context is base DashboardContext

// after
if (context is AspNetCoreDashboardContext aspNetContext)
{
    var http = aspNetContext.HttpContext;
}

if (context is AspNetCoreDashboardContext aspNet) { var http = aspNet.HttpContext; /* safe */ }

static bool IsAspNetCoreContext(DashboardContext context) => context is AspNetCoreDashboardContext;

DashboardContext context = /* ... */;
try { var http = context.GetHttpContext(); }
catch (ArgumentException ex) when (ex.ParamName == nameof(context))
{
    // context is not AspNetCoreDashboardContext; fall back to IHttpContextAccessor
}

When it happens

Trigger: Calling context.GetHttpContext() on a DashboardContext instance that is not AspNetCoreDashboardContext — e.g., in a custom IDashboardAuthorizationFilter, a custom Razor page, a unit test that new'd up a bare DashboardContext, or dashboard code running outside the ASP.NET Core hosting pipeline.

Common situations: Porting an OWIN-based dashboard filter to ASP.NET Core without updating the context type; unit-testing dashboard authorization with a hand-built DashboardContext; using a third-party Hangfire dashboard wrapper that passes its own context subclass.

Related errors

• DelaysInSeconds value must be an array of non-negative numbe
• value
• Resource with name {resourceName} not found in assembly {ass
• MonitoringApi should inherit the `JobStorageMonitor` class
• routes

AI-assisted analysis of HangfireIO/Hangfire@c236dd0f93 (2026-08-13). Data as JSON: /api/errors/f6fef818a0831e84. Report an issue: GitHub.