I am trying to diagnose this error when my timer function runs. I have not found much help on this on google search
UnscheduledInvocationReason: IsPastDue, OriginalSchedule: 2019-06-13T15:13:00.0000000-07:00
It seems like the process just stops when this error comes.
Anyone have any insight on this?
The IsPastDue flag is passed to your azure function to indicate if the timer was overdue or not. A timer function can run late in some scenarios like the app service was restarted, in this case it is still invoked but the IsPastDue flag will be set to true to give your function a chance to react.
These links are helpful
Timer trigger for Azure Functions
Also, it seems that it was an issue and it is submitted on github but that was on 2017
TimerTrigger can miss IsPastDue
Got this error locally.
[2021-06-16T14:58:22.779Z] Executing 'Functions.TimerTrigger'
(Reason='Timer fired at 2021-06-16T16:58:22.7688953+02:00',
Id=adbaee54-8a3e-4983-a7e4-a73f69153e5e) [2021-06-16T14:58:22.780Z]
Trigger Details: UnscheduledInvocationReason: IsPastDue,
OriginalSchedule: 2021-06-16T16:37:00.0000000+02:00
[2021-06-16T14:59:22.614Z] Starting worker process failed
[2021-06-16T14:59:22.615Z] The operation has timed out.
Solved by clearing Blob Emulator locally:
delete
FROM [AzureStorageEmulatorDb510].[dbo].[Blob]
Related
I'm trying to run Azure Orchestrations and I sunddenly I started getting the error from the statusQueryGetUri:
Orchestrator function 'UploadDocumentOrchestrator' failed: The function 'UploadDocumentOrchestrator' doesn't exist, is disabled, or is not an orchestrator function.
I've run this functions dozens of times today without any issue. VSCode doesn't flag any issues. I've tried restarting and that hasn't helped either.
This has happened once before. I got the error, troubleshot for like 3 hours, got frustrated, left, and came back to my computer an hour later and the problem was resolved without changing anything. I suspect the issue is related to caching somehow, but I'm not sure where to fix this.
There is a similar issue noted at:
https://github.com/Azure/azure-functions-durable-extension/issues/577
After I run func start, my "missing" orchestration appears in the launch screen indicating that it is valid as shown below.
I start the UploadDocumentOrchestrator with the HttpTrigger StartUploadDocuments. I see the trigger complete its execution UploadDocumentOrchestrator never starts in the logs.
UploadDocumentOrchestrator: orchestrationTrigger
For detailed output, run func with --verbose flag.
[2023-01-11T19:58:10.490Z] Executing 'StartUploadDocuments' (Reason='This function was programmatically called via the host APIs.', Id=f158ac3e-fa39-403c-9671-307ea54d5948)
[2023-01-11T19:58:10.599Z] Started orchestration with ID = '29b9ab7fcffe4f59bd47032ef21c19e8'.
[2023-01-11T19:58:10.620Z] Executed 'StartUploadDocuments' (Succeeded, Id=f158ac3e-fa39-403c-9671-307ea54d5948, Duration=154ms)
[2023-01-11T19:58:13.952Z] Host lock lease acquired by instance ID '0000000000000000000000004906C298'.
As it mentioned in the Same GitHub Ticket, it is solved by clearing the Azure storage emulator data, check here.
It might be due to the Caching issue and also #ConnorMcMahon given another scenario in GitHub Issue #1381 of the same error - renaming the function caused the same issue for a few users:
The function ‘XYZ’ doesn’t exist, is disabled, or is not an orchestrator function.
I have a function app, that was running once a month on 26th for a few months, but for a business reason we disabled the run. When we turned it back today 14th, it got triggered automatically stating the previous run was missed
Message Trigger Details: UnscheduledInvocationReason: IsPastDue, OriginalSchedule: 2022-05-26T14:05:00.0000000-05:00
Is there any way not to run the previous missed days?
Error "UnscheduledInvocationReason" occurs when either RunOnStartup or isPastDue property is set to true. See code
isPastDue property is set to true when the current function invocation is later than scheduled(for example if a function was restarted) See code
You can set UseMonitor = false to disable "UnscheduledInvocationReason" due to isPastDue.
Azure Function TimerTrigger uses the Singleton feature of WebJobs SDK to ensure that a single instance of a function app is running by acquiring a Blob lease, the log you are observing here is regarding this singleton behavior. See documentation
https://learn.microsoft.com/en-us/answers/questions/110043/unscheduledinvocationreason-ispastdue-originalsche.html
I have deployed a change to a durable function product into Azure DevOps and part of the work was to rename an activity function.
However the warning below is appearing in the log stream containing the old name for the function.
[Warning] Activity function 'PublishNotification' does not exist..
InstanceId: . Function: PublishNotification.
This function publishes a message to a Service bus topic, and there is definitely now no reference to that function name anywhere in the code.
Any ideas where this might be coming from?
From your description, it seems that your function name has been changed, the orchestrator function listener and other function listeners are been deregistered:
https://github.com/Azure/azure-functions-durable-extension/blob/f6f1dce716b68d8baaa99ed64a9db1306577c58d/src/WebJobs.Extensions.DurableTask/Listener/DurableTaskListener.cs#L44-L54
But the orchestrator function is still running, and it cannot find your previous function name:
https://github.com/Azure/azure-functions-durable-extension/blob/f6f1dce716b68d8baaa99ed64a9db1306577c58d/src/WebJobs.Extensions.DurableTask/DurableOrchestrationContext.cs#L385
If you restart the function app and let everything start again, can you still reproduce this error?
I went into the Azure web job storage queues and had a look around. Turns our there was an old message (about 4 days old) stuck in one of the queues and when that was cleared out the warning messages disappeared too.
I have also asked this question in the MSDN Azure forums, but have not received any guidance as to why my function goes idle.
I have an Azure function running on a Consumption plan that goes idle (i.e. does not respond to new messages on the ServiceBus trigger queue) despite following the instructions outlined in this GitHub issue:
The configuration for the function is the following json:
{
"ConnectionStrings": {
"MyConnectionString": "Server=tcp:project.database.windows.net,1433;Database=myDB;User ID=user#project;Password=password;Encrypt=True;Connection Timeout=30;"
},
"Values": {
"serviceBusConnection": "Endpoint=sb://project.servicebus.windows.net/;SharedAccessKeyName=SharedAccessKeyName;SharedAccessKey=KEY_HERE",
}
}
And the function signature is:
public static void ProcessQueue([ServiceBusTrigger("queueName", AccessRights.Listen, Connection = "serviceBusConnection")] ...)
Based on the discussion in the GitHub issue, I believed that having either a serviceBusConnection entry OR an AzureWebJobServiceBus entry should be enough to ensure that the central listener triggers the function when a new message is added to the ServiceBusQueue, but that is proving to not be the case.
Can anyone clarify the difference between how those two settings are used, or notice anything else with the settings I provided that might be causing the function to not properly be triggered after a period of inactivity?
I suggest there are several possible causes for this behavior. I have several Azure subs and only one of them had issues with Storage/Service Bus-based triggers only popping up when app is not idle. So far I have observed that actions listed below will prevent triggers from working correctly:
Creating any Storage-based trigger, deleting (for any reason) the triggering object and re-creating it.
Corrupting azure function input parameters by deleting/altering associated objects without recompiling a function
Restarting functions app when one of the functions fails to compile/bind to trigger OR input parameter and hangs may cause same problems.
It has also been observed that using legacy Connection Strings setting for trigger binding will not work.
Clean deploy of an affected function app will most likely solve the problem if it was caused by any of the actions described above.
EDIT:
It looks like this is also caused by setting Authorization/Authentication on the functions app, but I have not yet figured out if it happens in general or when Auth has specific configuration. Tested on affected Azure sub by disabling auth at all - function going idle after 30-40 mins, queue trigger still initiates an execution, though with a delay as expected. I have found an old bug related to this, but it says issue resolved.
I am using a Mobile Services in Windows Azure. I use the new Scheduler available for a Mobile Service. The Scheduler I called SendOut.
I am running a pretty simple script that will insert a message to a queue. The entire script:
function SendOut() {
var azure = require('azure');
var queueService = azure.createQueueService("mailsoutscheduler", "[The key to the storage]");
queueService.createQueueIfNotExists("mailsout", function(error){ });
queueService.createMessage("mailsout", "SendOut", function(error){});
}
It works fine when I try to run the script once. It it scheduled to run every 5 minutes. And it usually goes fine. However sometimes I receive this error:
An unhandled exception occurred. Error: One of your scripts caused the
service to become unresponsive and the service was restarted. This is
commonly caused by a script executing an infinite loop or a long,
blocking operation. The service was restarted after the script
continuously executed for longer than 1000 milliseconds.
at EventEmitter. (C:\DWASFiles\Sites\VogSendOut\VirtualDirectory0\site\wwwroot\runtime\server.js:84:17)
at EventEmitter.emit (events.js:88:20)
I cannot figure out why I get this error - or how to solve it.
Could it be because it's running in the FREE Mobile Service Tier?
I don't think it's due to the FREE mobile subscription.
try to add a
try{}
catch{} block
and use console.log() to log if an error occured. It could help you to resolve you problem.