TimerTrigger fires at unexpected times when RunOnStartup = true

[jonmclean]

When RunOnStartup = true the Timer Trigger seems to fire every time a host is started / restarted.

Example function definition:
        public static void Run(
            [TimerTrigger("0 0 1 * * *", RunOnStartup = true)] TimerInfo timer, // at 1am UTC 
            [Queue(QueueConstants.RedditPostQueueName, Connection = QueueConstants.QueueConnectionStringName)] ICollector<SocialGistPostBatch> queueCollector,
            ExecutionContext executionContext,
            TraceWriter logger
        )

I would expect this to fire when manually starting / restarting the Azure Function through the Portal. I would also expect this to fire every time a new version is deployed. It seems that it fires many whenever the engine restarts a host or moves to a different host. If this is the expected behavior please make all trigger conditions very clear in the documentation.

I have attached a screenshot of App Insights events during one of the unexpected runs.

[paulbatum]

This is expected behavior for RunOnStartup.

https://github.com/Azure/azure-webjobs-sdk-extensions/blob/7bc24be6ef2ef6b79682f0085a3ad56d34da1af8/src/WebJobs.Extensions/Extensions/Timers/TimerTriggerAttribute.cs#L61-L66

[jonmclean]

I was confused by the documentation. The term "startup" appears to be overloaded. I assumed that the "initial startup run" mentioned in the docs above referred to the overall function app startup/deploy and not the startup on a new server after the app is migrated.

It would also be useful to allow a function to be run a single time after the user manually clicks the "start" or "restart" buttons in the Azure portal without causing a run after each back-end server migration.

Please consider clarifying the documentation. One thought:

The function will be run once when the function app is started and each time the function app is automatically migrated to a new host. The function will also be run on the specified schedule.

[paulbatum]

Yeah makes sense, I think this is one of those cases where the fact that webjobs attributes can be used for both webjobs and functions makes things confusing. We can't have one set of XML documentation that appears for webjobs and another that appears for functions.

[paulbatum]

Reopening this. We should consider just ignoring this setting in certain contexts.