Two TickerQ runners on the same DB creates SQL errors

[MaxAllan-Smith]

Issue Description

I’ve set up Program.cs with TickerQ as follows:

using Microsoft.EntityFrameworkCore;
using TickerQ.Dashboard.DependencyInjection;
using TickerQ.DependencyInjection;
using TickerQ.EntityFrameworkCore.DependencyInjection;
using UcSmsService.Api.Data;
using UcSmsService.Api.Exceptions;

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
    options.UseSqlServer(builder.Configuration.GetConnectionString("Default"));
});

builder.Services.AddTickerQ(options =>
{
    options.SetMaxConcurrency(1);
    options.SetExceptionHandler<TickerExceptionHandler>();
    options.AddOperationalStore<ApplicationDbContext>(efOptions =>
    {
        efOptions.UseModelCustomizerForMigrations();
        efOptions.CancelMissedTickersOnAppStart();
    });
    options.AddDashboard(dash => { dash.EnableBasicAuth = true; });
});

builder.Services.AddControllers();
builder.Services.AddOpenApi();

WebApplication app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
app.UseTickerQ();

app.Run();

Note:

options.SetMaxConcurrency(1);

---

Job Class

I also have a simple job defined as:

using TickerQ.Utilities.Base;
using TickerQ.Utilities.Enums;

namespace UcSmsService.Api.Jobs
{
    public class TickerJobs(ILogger<TickerJobs> logger)
    {
        [TickerFunction("Heartbeat", "* * * * *", TickerTaskPriority.High)]
        public void Heartbeat(CancellationToken cancellationToken)
        {
            logger.LogInformation(" ################## Hello World! Test! #####################");
        }
    }
}

The cron expression "* * * * *" schedules it to run every minute.

---

Problem

• When the application is started for the first time, the job runs as expected.
• However, if the application is stopped and restarted within the same minute, I immediately get a long exception trace caused by a SQL constraint violation.

---

Error Logs

Here are the relevant parts of the error messages:

fail: Microsoft.EntityFrameworkCore.Database.Command[20102]
      Failed executing DbCommand (2ms) [Parameters=[...]]
      INSERT INTO [ticker].[CronTickerOccurrences] (...)
      VALUES (...)

fail: Microsoft.EntityFrameworkCore.Update[10000]
      An exception occurred in the database while saving changes for context type 'UcSmsService.Api.Data.ApplicationDbContext'.
      Microsoft.EntityFrameworkCore.DbUpdateException: An error occurred while saving the entity changes.

Microsoft.Data.SqlClient.SqlException (0x80131904): 
      Cannot insert duplicate key row in object 'ticker.CronTickerOccurrences' 
      with unique index 'UQ_CronTickerId_ExecutionTime'. 
      The duplicate key value is (5be4f7dc-42fc-4a10-b5d9-679df89b0ca0, 2025-09-03 10:31:00.0000000).
      The statement has been terminated.

warn: TickerQ.EntityFrameworkCore.Infrastructure.TickerEfCorePersistenceProvider[0]
      Constraint violation handled gracefully for CronTickerId=5be4f7dc-42fc-4a10-b5d9-679df89b0ca0, ExecutionTime=2025-09-03 10:31:00

---

Summary

• Expected: The job should either skip or safely re-schedule if the app restarts in the same minute.
• Actual: Restarting within the same cron interval causes a duplicate insert into CronTickerOccurrences.

This seems related to how TickerQ handles missed or overlapping occurrences when the app restarts quickly.

---

Extra Context

I consulted ChatGPT (GPT-5) about this issue.
The suggestion was that the problem could be tied to how CancelMissedTickersOnAppStart() and occurrence seeding interact: when the app restarts mid-minute, TickerQ might try to re-insert the same scheduled occurrence, triggering the SQL unique constraint.

Potential fix areas (according to ChatGPT’s analysis):

• Adjusting how missed occurrences are cancelled on startup.
• Adding a safeguard so duplicate minute-occurrences are not re-inserted.

[arcenox]

@MaxAllan-Smith did u use the latest version, v2.5.3?

[MaxAllan-Smith]

@arcenox I did yes

[MaxAllan-Smith]

@arcenox If you are struggling to replicate the issue locally or if I am doing something wrong, I am available for a call

[arcenox]

@MaxAllan-Smith The errors you’re seeing are already handled on the database side using commit/rollback transactions. The issue comes from EF Core itself, which raises errors that can’t simply be silenced — even though in practice they behave more like warnings.

I’m currently working on releasing dedicated TickerQ builds for .NET 8 and later. These versions will leverage EF Core’s improved flexibility to handle these scenarios more cleanly and give us a better way to make the necessary adjustments.

[MaxAllan-Smith]

@arcenox awesome, I'll keep my eye's peeled for the next release

[MaxAllan-Smith]

@arcenox has there been any updates on this? Have you got a rough ETA for the next release?