JeffC
My feedback
-
130 votes
This feature is now on our roadmap. There is no ETA for when this feature will become available but we will update here when work on this feature has started.
Thank you for your suggestion.
JeffC
supported this idea
·
-
55 votes
Nothing planned short term but a great ask. This is an item that could potentially be contributed if interest to do so earlier. Hoping we get this planned soon.
-
JeffJeffC
supported this idea
·
JeffC
commented
I can see how this would be useful in some situations. I guess you'd have to have a setting for the max number of items to fetch from SB. Then your main function method (Run) would need to have the arguments expect a list of message objects.
-
63 votes
This continues to be unplanned. Please keep the votes coming!
- Matthew
JeffC
supported this idea
·
JeffC
commented
For sure Azure SQL. We're using Service Bus as a go between now but it would be better to have a SQL trigger.
-
79 votes
Moving this work item to unplanned, as it is clear that this request is no for a global throughput limit.
We do now offer the ability to limit your maximum instances in the Premium plan, which will allow you to avoid swamping downstream resources. https://docs.microsoft.com/en-us/azure/azure-functions/functions-premium-plan#plan-and-sku-settings
We prioritized that above a max call per X limit, because our only control to limit throughput is to outright deny some number of requests above a threshold.
Keep the feedback coming!
Alex
Azure Functions TeamJeffC
supported this idea
·
JeffC
commented
I'd like to have this ability to protect our functions from misuse.
-
14 votesJeffC
shared this idea
·
-
234 votesJeffC
commented
This is the #1 missing feature that prevents me from going live with Azure Scheduler. I have jobs that need to run at specific local times across timezones all around the world.
Examples: job1 run at 3am PST Los Angeles, job2 run at 3am EST New York, job3 run 3am IST Dublin.
For a scheduler to work for our needs there must be the ability to schedule the job to run in a specific timezone and then the scheduler must account for daylight savings time to be sure the job always runs at the correct local time.
We are using a home grown scheduler that is short on features and I'd like to leave it to run on Azure but timezone and DST support is a showstopper for us. Our homegrown system has been able to handle this for years. A few lines of C# can handle the conversion between future job schedule time and UTC and will account for what the target timezone DST offset will be (if any) at the scheduled date and time.
This would be extremely helpful. We have to use DateTimeOffset for proper date handling and display throughout our application and SQL Server does it quite well. But I want to move part of our application over to Cosmos DB and can't do it until there is support for DTO.