I receive the following error while publishing and Azure Website from Visual Studio 2013:
12>Publish Succeeded. 12>Creating the scheduler job
12>C:\projectPath\packages\Microsoft.Web.WebJobs.Publish.1.0.7\tools\webjobs.console.targets(110,5):
Error : An error occurred while creating the WebJob schedule: Response
status code does not indicate success: 400 (Bad Request).
I have read another posts with similar issues: 404 error, BadRequest: The condition specified by the ETag is not satisfied... but none of these seem to be the problem here. I have reinstalled the Microsoft Azure Tools for VS 2013, the webjobs.publish package in my solution and it didn't work either. I also checked this post https://social.msdn.microsoft.com/forums/azure/en-US/d5b44e53-c4d7-48ff-a024-4bdd6eb48b79/sheduled-web-jobs-in-azure-web-site-not-configurable-in-same-region-as-web-siteand-workaround?forum=azurescheduler#d5b44e53-c4d7-48ff-a024-4bdd6eb48b79 and did what he tried but it haven't solved the issue.
It looks like all my files are uploaded correctly to the Azure website, and the issue begins when the scheduler jobs are being created.
The strange thing is that the webjobs are uploaded (updated) and that they are also working correctly, but the scheduled webjobs are not in my jobcollection list in the Azure management portal. I also tried to remove my current job collection and all the jobs from my website, but when I publish the site, all the webjobs are created but the job collection is empty.
I had a similar issue with VS and the problemas was that the credentials of the website were expired, but the problem was solved by reentering the credentials in VS. Any idea of how to solve this issue?
Please see my answer to Visual Studio 2015 Publish WebJobs Issue, which shows an alternate way to do scheduling that makes things far simpler and avoids this type of conditions.
To summarize, you can create a settings.job file at the root of your WebJob file, containing a CRON expression. e.g.
{
"schedule": "0 0 * * * *"
}
For more information, about this technique, see the following documentation links:
https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/#CreateScheduledCRON
http://blog.amitapple.com/post/2015/06/scheduling-azure-webjobs/
I faced the same issue today and the solution for me was simpler. What happened is that the startTime I had configured on my webjob-publish-settings.json was for some days ago (while I was developing). I changed the startTime for tomorrow and it worked. Looks like the scheduler is not able to get started when the startTime is not in the future. Hope it helps.
As I have noted in my question, I deleted my webcolletion to solve the issue, but I did not notice that the new collection was created in free mode (I do not know why because my site is in standard mode). So setting the jobcollection to standard mode partially solved the problem. Then I got the following error:
An error occurred while creating the WebJob schedule: Response status
code does not indicate success: 409 (Conflict).
I went to the azure portal, and I saw that all jobs but one were created correctly (as scheduled jobs). I reset the webjob-publish-settings.json file of the webjob, I published it and the problem was solved.
Related
Ran into an issue the other day that took me a few hours of head bashing to resolve. I hope if someone is having a similar issue I can save them some time. I have a new API i'm building and everything working as expected locally. Setup my dev and staging environments in azure then went about setting up my build and release pipelines. All of that is pretty straight forward as it's just a bunch of button clicking with a little yaml editing.
after the deploy I try to hit my API and bam! error 500. After a bunch of reading I see similar issues regarding AspNetCoreModule vs AspNetCoreModuleV2 and some issues with InProcess vs OutOfProcess.
I then deployed right from VS and amazingly everything worked. I can't do that EVERY time so went back to pipeline deploy and bam error 500 again.
"Detailed Error Information:
Module AspNetCoreModule
Notification ExecuteRequestHandler
Handler aspNetCore
Error Code 0x00000000"
And My Answer!
After comparing the output files from VS deploy and what's in the deploy artifact I realized my .xml comment files were missing in the artifact, the same comments used by swagger.... UGH...
Solution: Copy to Output Directory: Copy if newer - Lesson Learned!
I designed a CI/CD pipeline to deploy an ARM Template from github to create an instance of api management in my resource group using the ARM Template.
In my release logs, I am constantly getting this warning "Can\'t find loc string for key: CorrelationIdForARM" which is slowing down the process. Although after taking a long time the resource is successfully created still the release appears as failed.
logs
There appears to have been some change introduced by Microsoft that started prompting these warnings when using App Service-related steps. In my case, we use separate steps to first stop, deploy, then start an App Service, and each one of those steps contains at least five of these "warnings." We don't do anything advanced either, just simple deployments; no slot swaps, no ARM templates, just .NET Core code deployment.
Microsoft appears to have heard our complaints and already reported "we have merged the fix for the issue." Not sure how long until we will see that fix implemented however, as it appears to be more of an annoyance rather than something that breaks builds.
https://developercommunity.visualstudio.com/content/problem/859513/azure-app-service-manage-warnings.html
They just announced the solution for this is being deployed and should be fixed for all accounts by the end of the week:
Hi, the fix for CorrelationIdForARM warning is already merged and is under deployment. It should reach all the accounts by the end of this week. Thankyou for your patience.
Source: https://github.com/microsoft/azure-pipelines-tasks/issues/11996
still getting this error, its getting worse now. Agent Jobs just hanging now.
"Can\'t find loc string for key: CorrelationIdForARM"
Right now I again faced the issue that old code is used on an Azure Function App even after the zip deployment through KUDU returns success.
Of course, that is after some 30 mins that I expect the new code to get loaded, not immediately.
The issue is marked as closed.
What is considered to be the best practice in this case:
Programmatically force the Function App to restart, say, through Azure CLI or Powershell Az modules?
Or there is another way to mitigate the issue?
While restarting should fix it, my suggestion would be to enable "Run from package": https://learn.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package. That removes the chance of having old files running as the deployment is atomic.
You'd set an app setting of WEBSITE_RUN_FROM_PACKAGE to 1 and continue deploying the same way you are today. The site will be run directly from that package (wwwroot will appear as read-only in kudu) so there's no unzipping and copying, which may be causing the issue you're having.
Note: it looks like we're still tracking the issue here: https://github.com/Azure/azure-functions-host/issues/2636.
In my case the issue lay in the CI-CD pipelines, where an out-of-date artifact was being deployed - thus the successful deploy, but the old code.
As of Wednesday, sometime between 2:01 pm and 2:43 pm Eastern, Visual Studio Team Service Release Management began failing in the Azure Web App Deployment Task, during the Deploy Website to Azure step with the generic error:
You cannot call a method on a null-valued expression
We created a new Release Definition, but it exhibits the same issue.
I attempted a Release with the previously successful version of the build, and it too exhibits the same exception.
I have verified that there is no deploy.cmd in the repository.
I have verified the items in the change set for the build.
They only touched one .cs file, three .js files, and changed the value of the <add key="Client.CacheVersion" value="X"> from 4 to 6.
Though the documentation states that the -ErrorVariable is valid for the script in question. The only difference in the log files (pre-failure information) is the addition of -ErrorVariable publishAzureWebSiteError to the end of the Publish-AzureWebsiteProject call.
Is there anyway to either populate the publishAzureWebSiteError, or remove this extraneous variable?
UPDATE:
After adding system.debug. I see that I am unable to resolve {mysite}.scm.azurewebsites.net.
UPDATE II
After 2 hours with Microsoft it appears that Release Management is having some difficulty working with App Service Environments. At first it was unable to map the scm URL appropriately and once we added the expected suffix to the Web App Name field we received the error:
Conflict: The host name MY_WEB_APP.APP_SERVICE_NAME.p.azurewebsites.net is already assigned to another Azure website: MY_WEB_APP.
FINAL UPDATE
It appears that the releases are now running as expected with in at least on the previously failing releases no changes were made. Since MS clearly changed something on their end, this question will provide no benefit to future users. I am voting to close it.
As this question has yet to be closed.
For those that come after:
The fix came from Microsoft. Premier support emailed me with the following this morning:
I just spoke to the developer who pushed the fix. And the fix has to do with correctly forming a SCM name which in your case is part of ASE. So there were no exceptions being raised this time and it worked for you.
So there are/were no workarounds, nor changes even possible on the part of the end user.
I'm working with Azure WebJobs, converting my task schedulers to WebJobs (my task scheduler is an .exe) When I run the WebJob OnDemand, after it runs for 4 to 5 hours its status is changing to Aborted and my data is not updated in my database. When I Googled this, I found one potential solution regarding Graceful Shutdown here:
The graceful period can be updated for any WebJob, the way to do
it is to create a file called settings.job with the following content:
{ "stopping_wait_time": 60 }
I've tried this, adding the property "stopping_wait_time": 1800 to my settings.job file and put the file in my site at app_Data/jobs/myjobname/myjobname/settings.job
However, this hasn't helped me. Can anyone help? Thanks in advance.