Search code examples
c#azure-webjobs

Time trigger webjob, won't trigger.. until i change name

I have a webjob in sdk 3.

 public class NotificationsFunction
{
    public async Task CustomerNotificationFunctionAsync([TimerTrigger("0 * * * * *")]TimerInfo myTimer, ILogger log)
    log.LogInformation("Running job");

It used to run correctly.Now, if i try to debug it locally, it just hangs.. It finds the functions but never trigger it: enter image description here

Now, if i just change the name in :

public class NotificationsFunction
{
    public async Task CustomerNotificationFunctionAsyncTest([TimerTrigger("0 * * * * *")]TimerInfo myTimer, ILogger log)
    log.LogInformation("Running job");

It runs perfectly: enter image description here

I have the same exact problem when i deploy to azure. I have no idea why this happens (and it took me a while to find this problem)...

As anyone ever had this problem? If so, what can I do? Thanks

Solution

  • From this document:

    TimerTrigger uses the Singleton feature of the WebJobs SDK to ensure that only a single instance of your triggered function is running at any given time. When the JobHost starts up, for each of your TimerTrigger functions a blob lease (the Singleton Lock) is taken. This distributed lock ensures that only a single instance of your scheduled function is running at any time. If the blob for that function is not currently leased, the function will acquire the lease and start running on schedule immediately. If the blob lease cannot be acquired, it generally means that another instance of that function is running, so the function is not started in the current host.

    The lock ID is based the fully qualified function name.

    According to your webjob in sdk 3, you could use AddAzureStorageCoreServices.

    var builder = new HostBuilder()
    .ConfigureWebJobs(b=>
    {
        b.AddTimers();
        b.AddAzureStorageCoreServices();
    })
    .Build();

    I have the same exact problem when i deploy to azure.

    Also note that if you're sharing the same storage account between your local development and production deployment, the Singleton locks (blob leases) will be shared. To get around this, you can either use a separate storage account for local development or perhaps stop the job running in Azure.