This issue only occurs when I use the Azure Portal Editor. If I upload from Visual Studio, this issue does not occur, but I cannot upload from Visual Studio due this unrelated bug: Azure Functions - only use connection string in Application Settings in cloud for queue trigger.
When using the Azure Portal Editor, if I throw an exception from C# or use context.done(error) from JavaScript, Application Insights shows an error occurred, but the message is simply consumed. The message is not retried, and it does not go to a poison queue.
The same code for C# correctly retries when uploaded from Visual Studio, so I believe this is a configuration issue. I have tried modifying the host.json file for the Azure Portal Editor version to:
{
"queues": {
"visibilityTimeout": "00:00:15",
"maxDequeueCount": 5
}
}
but the message was still getting consumed instead of retried. How do I fix this so that I can get messages to retry when coding with the Azure Portal Editor?
Notes:
In JavaScript, context.bindingData.dequeueCount returns 0.
Azure Function runtime version: 1.0.11913.0 (~1).
I'm using a Consumption App Plan.
I was using the manual trigger from the Azure Portal Editor, which has different behavior from creating a message in the queue. When I put a message in the queue, the Azure Function worked as expected.
For local development, if your function is async use Task for the return type.
public async Task Run
instead of void:
public async void Run
Related
I ran into an issue while migrating an Azure app service from .Net Core 5 to 6 while also updating the stack configuration in Azure Portal to use .Net version ".Net 6 (LTS)". The app service only contains continuous webjobs that process service bus messages. Locally, the webjob project runs fine but when deployed to Azure it fails to start. In Kudu tools I'm presented with an error:
[01/03/2023 18:21:32 > 1b0f90: ERR ] Unhandled exception. System.IO.IOException: Failed to bind to address http://127.0.0.1:5000: address already in use.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> Microsoft.AspNetCore.Connections.AddressInUseException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
[01/03/2023 18:21:32 > 1b0f90: ERR ] ---> System.Net.Sockets.SocketException (10048): Only one usage of each socket address (protocol/network address/port) is normally permitted.
Eventually I am able to get past the error by applying the app setting ASPNETCORE_URLS=http://localhost:5001 to the app service, and applying the same app setting every .Net Core 6 app service running web jobs in the same app service plan except I have to increment the port to something different. This does not seem to be a problem with non-webjob applications, and only occurs when I configure the app service stack to ".Net 6 (LTS)" in Azure Portal.
My question is: Is there another workaround to this issue? I find adding unique port assignments to every webjob running .Net 6 to be a cumbersome and not ideal, and this issue will exist as a serious gotcha for future development.
Here is the dependencies I am pulling in:
Azure.Messaging.ServiceBus Version=7.11.0
Microsoft.Azure.WebJobs Version=3.0.32
Microsoft.ApplicationInsights.AspNetCore Version=2.21.0
Microsoft.ApplicationInsights.NLogTarget Version=2.21.0
Microsoft.Azure.Services.AppAuthentication Version=1.6.2
Microsoft.Azure.WebJobs.Extensions Version=4.0.1
Microsoft.Azure.WebJobs.Extensions.ServiceBus Version=5.3.0
Microsoft.Azure.WebJobs.Extensions.Storage Version=5.0.1
NLog Version=5.0.4
NLog.Targets.Seq Version=2.1.0
NLog.Web.AspNetCore Version=5.1.4
To reproduce:
Create two or more .Net Core 6 applications that only implement Webjobs. My Webjobs functions process Service Bus topic messages, not sure if this is important to reproduce.
Deploy the Webjob applications to the same App Service Plan
In the configuration blade settings tab for each web app make sure that the runtime stack is set to ".Net 6 (LTS)", keep the rest as default.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
The problem seems to be around setting the stack settings version to ".Net 6 (LTS)". From this article it seems that this setting makes the app service Run Kestrel with YARP, I'm guessing the feature parity is not 1:1 with the previous stack.
Example project that can reproduce the issue can be found on Github. Follow README found in .\Scripts to deploy example to Azure.
Note: there seems to be an issue with the template setting the stack to .Net 6. This may need to be done manually post deployment to fully reproduce the issue.
I have created 2 .NET Core 6 Applications and deployed to Azure Web Jobs in same Azure App Service.
Make sure to enable Always On option in App Service => Configuration => General Settings to ensure WebJobs are running Continuously.
I have updated the Stack settings run time Version to .NET 6.
Now when you go to view the webjobs in Azure Portal you will see that the job is stuck in a restart cycle.
Yes, even I got stuck with the same issue. The WebJob which I have published 2nd is showing the Pending Restart status.
When I click on the Logs, I can see the below error is Logged.
Make sure that you are setting a connection string named >`AzureWebJobsDashboard` in your Microsoft Azure Website >configuration by using the following format >`DefaultEndpointsProtocol=https;AccountName=**NAME**;Account>Key=**KEY**` pointing to the Microsoft Azure Storage account where >the Microsoft Azure WebJobs Runtime logs are stored.
In the second Console App, I haven't Configured the WebJobs and Storage Account.
Updated the code and published again.
Now I can see both the Jobs are in Running State.
My Program.cs file:
// See https://aka.ms/new-console-template for more information
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
namespace WebJobApp
{
class Program
{
static async Task Main()
{
var builder = new HostBuilder();
builder.UseEnvironment(EnvironmentName.Development);
builder.ConfigureWebJobs(b =>
{
b.AddAzureStorageCoreServices();
b.AddAzureStorageQueues();
});
builder.ConfigureLogging((context, b) =>
{
b.AddConsole();
});
var host = builder.Build();
using (host)
{
await host.RunAsync();
}
}
}
}
Reference taken from MSDoc.
I have azure functions developed in node js. When I create a cloud instance for function app, it gets stuck on deployment process with all the resources OK status. Microsoft.Web/serverfarms returning 429. The error message reads as:
**"status"**: "Failed",
**"error"**: {
**"code"**: "429",
**"message"**: "App Service Plan Create operation is throttled for subscription <subcription_id>. Please contact support if issue persists.",
}
Please let me know what the possible solution will be for this
Turns out, you just need to create a new function application with different server location. and delete all the related instances of the previously deployed azure function.
I have a basic QueueTrigger Azure function. When I disable the function in the azure portal it's still pulling messages off the storage queue (because when I look at the queue in the Azure Queue Storage Explorer the queue is empty and if i add a message it is immediately pulled off).
Here is the code:
[FunctionName("ProcessMessage")]
public static void Run([QueueTrigger("queue-name", Connection = "queue-connection")] Models.Message message, TraceWriter log)
{
log.Info($"C# Queue trigger function processed: {message}");
}
I noticed that when I stop the whole functions app it stops processing messages off the queue, but I was hoping that I could disable queue processing temporarily without stopping the whole function app. How does one do that?
Thanks!
Disabling the V1 function created in Visual Studio does not work in the azure portal. You should use the attribute:
https://learn.microsoft.com/en-us/azure/azure-functions/disable-function#functions-1x---c-class-libraries
(see important section)
In my small job, I just use same Storage Account for AzureWebJobsDashboard and AzureWebJobsStorage configs.
But what happened when we use same connection string for local Debugging and Published job equally? Are they treated in isolated manner? Or do they have any conflict issue?
I looked into blobs of published job and found azure-webjobs-dashboad/functions/instances or azure-webjobs-dashboad/functions/recent/by-job-run/{jobname}, or azure-webjobs-hosts/output-logs directories; they have no discriminator specified among jobs while some other directories have GUID with job name.
Note that my job will be run in continuous.
Or do they have any conflict issue?
No, there is no conflict issue. Base on my experience, it is not recommended to local debugging while Published job is running in the azure with the same connection string. Take Azure Storage queue for example, we can't control which queue should be executed in the local or in the azure. If we try to use debug it locally, please have a try to stop the continue WebJob from Azure Portal.
If we try to know WebJob is executed from which instance we could log the instance info in the code with the environment variable WEBSITE_INSTANCE_ID.The following is the code sample:
public static void ProcessQueueMessage([QueueTrigger("queue")] string message, TextWriter log)
{
string instance = Environment.GetEnvironmentVariable("WEBSITE_INSTANCE_ID");
string newMsg = $"WEBSITE_INSTANCE_ID：{instance}, timestamp：{DateTime.Now}, Message：{message}";
log.WriteLine(newMsg);
Console.WriteLine(newMsg);
}
More info please refer to how to use azure queue storage with the WebJob SDK. The following is snipped from the document.
If your web app runs on multiple instances, a continuous WebJob runs on each machine, and each machine will wait for triggers and attempt to run functions. The WebJobs SDK queue trigger automatically prevents a function from processing a queue message multiple times; functions do not have to be written to be idempotent
Update :
About timer trigger we could find more explanation of timer trigger in the WebJob from the GitHub document.So if you want to debug locally, please have a try to stop the WebJob from the azure portal.
only a single instance of a particular timer function will be running across all instances (you don't want multiple instances to process the same timer event).
The new azure function preview contains a few templates for C#. But there is no service bus queue template for C#. There is a trigger template for node with service bus. But on close inspection, it only supported Notification Hubs and not service bus queue. Is it even possible to write an azure function that can only be triggered when an item appears in azure service bus queue? If it is not possible now, will there be such a template in the near future?
Thanks.
Raghu/..
Update: The below steps and information still hold, however we now have a "ServiceBusQueueTrigger - C#" template live in the portal, so the workaround steps are no longer necessary :)
ServiceBus IS supported already for C#, we just need to add a template for it (we'll add very soon). In general, templates are just starting points - you can always modify templates by adding additional bindings, or start from the empty template and build up your own Function.
Until we get the template uploaded, you can get this working yourself by starting from the C# Empty template. For example, you can enter binding info like the following in the Advanced Editor on the Integrate tab:
{
"bindings": [
{
"type": "serviceBusTrigger",
"name": "message",
"direction": "in",
"queueName": "samples-input",
"connection": "myServiceBus"
}
]
}
Make sure your Function App has an AppSetting matching the name of the connection property, containing your ServiceBus connection string. It looks like we currently have some issues with the connection string picker for ServiceBus (which will also be fixed very soon), but you can use "Function app settings"/"Go to App Service Settings"/"Application Settings" to add this app setting. Then you can use the corresponding Function code:
using System;
using Microsoft.Azure.WebJobs.Host;
public static void Run(string message, TraceWriter log)
{
log.Verbose($"C# ServiceBus Queue function processed message: {message}");
}
This function will then be invoked whenever new messages are added to ServiceBus queue samples-input.
Per https://azure.microsoft.com/en-us/documentation/articles/functions-reference/, there is no binding with the SB.
The best way to do that instead of doing something that is (at least by some chance) being in work in product group is to submit your idea on the UserVoice - https://feedback.azure.com/forums/355860-azure-functions .