Is there anyway of catching this GAS error: "Exceeded maximum execution time"
I mean catching with try ... catch(e) // so far it's not working for me.
Thanks
As written in the comments to your question, thats not possible. But, however, you can set a flag in scriptDB or properties when execution starts and clear that flag when execution comes to a normal end, so you can find out during the next run wether your script came to a regular end when it was run last time and try to take corrective actions if not.
The answer above is correct; it's not possible. An easy alternative to the workaround that pbhd mentioned would be to simply track the runtime of your script (e.g. comparing results of new Date().getTime() at regular intervals) and run whatever you'd include under your catch statement right before you hit the maximum execution time. The maximum is 6 minutes (reference).
That way, you don't have to catch the error -- you can preempt it.
During normal testing, it is possible to accidentally create an infinite (or very long running) loop that consumes the daily execution time limit 100%.
Even if you realize what you have dome wrong immediately, you cannot immediately re-try with Google scripts for another 24 hours - thus slowing down ongoing development significantly and maybe forcing the developer to do some other work , taking his focus/"attention stream" away from the current problem. This is almost always bad.
My product ("IBM OLIVER CICS test/debug" - see Wikipedia article) solved this problem - and many others - around 37 years ago - by having a time limit on any particular transaction and intercepting the resulting time out, allowing options of:-
continuation or
examine/modify variables
"manual" re-try (for the same time) or
abort.
Google could implement this approach just as easily - by "pausing" if execution time is looking too heavy. I had a similar solution to other resources in OLIVER - such as excessive API calls ("possible macro loop") and excessive memory usage.
It seems it takes an "old timer" like me to provide solutions to problems that have existed "since the beginning of time" (and certainly before PC's were thought of).
Googles current "solution" (i.e. absolute limits) only helps Google keep its own servers from being swamped. It would be easy for them to do what OLIVER did all those years ago. By the way there should be no "IBM" prefix on the Wikipedia article - it was my own product and some clown Wikipedia editor altered it to include the prefix.
(By the way, Google do not prevent other scripts on same s/s running - that maybe only use minimal amounts of extra time ( i.e. Scripts on the same spreadsheet still work) . I tried renaming the original script as an experiment but it was stopped after a very short time with "exceeded execution time" error.
GIZ-A-JOB Google - you know its worth it!
Related
This indicates that the script exceeded the total allowable execution time for one day. It most commonly occurs for scripts that run on a trigger, which have a lower daily limit than scripts executed manually. The limit as far as I am aware is 6 hours per day. None of my scripts run for that long.
Everything was fine earlier. Suddenly, over the last 3-4 days, all the scripts have started failing. I have no clue what's happening. My only hunch is that one of my scripts is going into an infinite loop. But still, if that happens, it will fail soon and collectively, all scripts would not run for 6 hours.
Please help to resolve this issue. I have a G suite id but Google mentioned that I get help at stackoverflow and that they cannot help.
The exception message should also tell you a lot about what is happening. If you are not sure which script is causing the issues you can try to go to the Google Apps Script Manager. In the menu bar on the left you will see a section called My Executions. If you click that you can see a list of scripts that ran and how long they ran for. This page also allows you to sort by duration and filter the results to hopefully help you figure out what is going on.
It possible that you have reached your quota. Having a Google Suite account allows you up to 6 hrs/day of Trigger Total Runtime. Also make sure you are not going over the limit on single script runtime as outlined here further down on the Quota For Google Services page.
For Google Suite Accounts the quota is:
Script runtime: 6 min/execution
Custom function runtime: 30 sec/execution
I had a similar problem. It's a little maddening because getting an error for the script leads one to believe it is a possible syntax problem. More likely, the script never ran in the first place, which is why you likely don't have a failed execution status for the trigger. What may have happened instead is that you have a script or scripts that are still firing for documents that no longer exist.
Navigate to "My Triggers" in the G Suite Developer Hub: https://script.google.com/home/triggers
Click on any time-based events and select "executions."
Search the "status" column for the words "Timed out," and check the duration.
Delete the trigger(s) that is timing out, or otherwise resolve why it is timing out (such as restoring the deleted document).
In my case, I had deleted several old spreadsheets, but one of my add-ons (Supermetrics) was still firing triggers. I had incorrectly assumed that when I deleted my spreadsheets the triggers would have gone with them. Instead they were firing and timing out after about six minutes, and then four hours later they would try to execute again. I added up the duration for all of these triggers and, sure enough, it exceeded my quota.
Delete those old triggers, and you'll likely be back within your quota limits the next day when it resets. This is what worked for me, but I imagine it's not a one-size fits all solution.
I have a "standard persistent disk" of size 10GB on Google Cloud using Ubutu 12.04. Whenever, I try to remove this, I encounter following error
The resource 'projects/XXX/zones/us-central1-f/disks/tahir-run-master-340fbaced6a5-d2' is not ready
Does anybody know about what's going on? How can I get rid of this disk?
This happened to me recently as well. I deleted an instance but the disk didn't get deleted (despite the auto-delete option being active). Any attempt to manually delete the disk resource via the dev console resulted in the mentioned error.
Additionally, the progress of the associated "Delete disk 'disk-name'" operation was stuck on 0%. (You can review the list of operations for your project by selecting compute -> compute engine -> operations from the navigation console).
I figured the disk-resource was "not ready" because it was locked by the stuck-operation, so I tried deleting the operation itself via the Google Compute Engine API (the dev console doesn't currently let you invoke the delete method on operation-resources). It goes without saying, trying to delete the operation proved to be impossible as well.
At the end of the day, I just waited for the problem to fix-itself. The following morning, I tried deleting the disk again, as it looks like the lock had been lifted in the meantime, as the operation was successful.
As for the cause of the problem, I'm still left clueless. It looks like the delete-operation was stuck for whatever reason (probably related to some issue or race-condition going on with the data-center's hardware/software infrastructure).
I think this probably isn't considered as a valid answer by SO's standards, but I felt like sharing my experience anyway, as I had a really hard time finding any info about this kind of google cloud engine problems.
If you happen to ever hit the same or similar issue, you can try waiting it out, as any stuck operation will (most likely) eventually be canceled after it has been in PENDING state for too long, releasing any locked resources in the process.
Alternatively, if you need to solve the issue ASAP (which is often the case if the issue is affecting any resource which is crtical to your production environment), you can try:
Contacting Google Support directly (only available to paid support customers)
Posting in the Google Compute Engine discussion group
Send an email to gc-team(at)google.com to report a Production issue
I believe your issue is the same as the one that was solved few days ago.
If your issue didn't happen after performing those steps, you can follow Andrea's suggestion or create a new issue.
Regards,
Adrián.
What is the term for a webhook that makes another set of webhooks?
A recent kludge (Unbounce, Zapier, Twilio) only allows me one webhook (i.e. custom one from Zapier)
https://zapier.com/zapbook/twilio/unbounce/
Eventually, however, I will need to generate multiple actions on different (customzed) platforms, so I was hoping to have a hook that goes to one place and then from there, vector off hooks to my other beta site (including Zapier).
Any suggestions would be greatly appreciated.
I note your question was about unbounce, but included Zapier. I'm assuming from this that you were looking to use Zapier as the "one place" (i.e in the middle)"
Now I don't know Zapier, but came across your question looking along the same lines. The terms I'm familiar with on this are "one-to-many", "fan-out" or "publish/subscribe" communication styles - but aware that these may be a bit old school in Web 2.0 world.
In my search I came across a Zapier Support post on Multiple Zaps.
In summary, looks like you may be able to achive this using a "Zapier Delay Trigger zap"
The possible downside (depending on delivery time requirements) is that the delivery of onward webhooks would be complete "...within 5-15 minutes". This doesn't quite fit my requirement, by may fit yours.
Edit: A quick search on "fan-out" term also found this on using Zapier Queue. Again,as it's queuing I suspect there may be a delay in onward processing.
Edit2: Following email to Zapier support - situation is still as per links i.e.time delay, but "...in your zap you can define the length of the delay to minimize the lag. This case you shouldn't have any problem setting a 1 minute delay since there's no need for it to be any longer, which can help you get a lot closer to 'near real time'."
Edit3: Further info from Zapier support - apparently if you configure two Webhook-Webhook Zaps you can fire them both with one URL as "https://zapier.com/hooks/catch/xxhook1,xyhook2" - appears to fire both zaps pretty immediately.
Edit4: One thing to watch with the multi-zap approach (as Edit3) is that if one send to target fails then you can replay manually (via Zapier site and paying customer) - there's no ability (currently) to manage automatic retrying (not sure if there's any ability to monitor this event).
I am a Google App Script user since last 2 years. I see here in India during peak time i.e during evening the 1 minute trigger is not firing at proper time. Is there any server side issue or there is some other issue. Saying about the worse case scenarios, today my script trigger has not been fired since past 2 hours. I have correctly done logging. No log is printed means it does not even go to that method. Can anybody tell me what might be the exact reason behind it.
It might be beneficial to show us the code behind your script, given that there is a method that is potentially being skipped over. Have there been no errors thrown to you via the Google Apps Script notifications?
It seems, perhaps, your issue may fall into place with this currently reported error: https://code.google.com/p/google-apps-script-issues/issues/detail?id=2708
We're likely not going to be able to give you a precise answer to your problem if we can't examine what you're currently working with. I wish you luck in your endeavor, though.
Today my co-worker noticed that when adding a decimal place to a progress indicator leads to the impression that the program is running faster than without. (i.e. instead of 1,2,3... it shows 1, 1.2, 1.4, 1.6, ...) I checked it and I was surprised that I got the same impression even though I knew it was faked.
That makes me wonder: What other things are there to create the impression of a fast application?
Of course the best way is to actually make the application faster, but from an algorithmic point of view often there's not much you can do. Additionally I think making a user less frustrated is a good thing, even though it is more or less a psychologic trick.
This effect can be very dramatic: doing relatively large amounts of work to give users a correct and often updating status of progress can of course slow down the actual running time of the application (screen updates, progress display needed calculations, etc) while still giving the user the feeling it takes less time.
Some of the things you could do in GUIs:
make sure your application remains responsive (resizing the forms remains possible, perhaps give a cancel button for the operation?) while background processing is occurring
be very consistent in showing status messages/hourglass cursors throughout the application
if you have something updating during an operation, make sure it updates often (like the almost ridiculous showing of filenames and registry keys during an install), or make sure there's an option to make it do this for users that like this behavior
Present some intermediate, interesting results first. "We've found 2,359 zetuyls matching your request, we're just calculating their future value".
I've seen transport reservation systems do that sort of thing quite nicely.
Showing details (such as the names of files being copied in an installation process) can often make things seem like they're going faster because there's constant, noticeable activity (as opposed to a slowly-creeping progress bar).
If your algorithm is such that it generates a list of results, and you have some way of displaying results as they're generated (as opposed to all at once at the end), do so - the sooner the user has something else to look at besides a spinner, the better.
Allow the user to do something else, while your application is processing data or waiting for a result. In application-scope you could allow to do some refinement of a search query or collect information for preparing next steps. Or just present some other "work" necessary to do or just some hints, documentation, statistics, entertainment..
Use one of those animated progress bars which look like they are doing something even when they aren't progressing. Also, as peSHIr said - print each filename that you copy and update it really fast - you could even fake it by cycling through a large string array N times a second.
I've read somewhere that if the process seems to be speeding up, it seems to be faster than when it's progressing at a steady pace. I can't find the reference right now, but it should be simple to implement.
(10 minutes later...)
A further look down Google lane unearthed the following references:
http://www.azarask.in/blog/post/hacking-memory/
http://blogs.msdn.com/time/
Here is an article about "Expressing time in your UI" and user perception of time. I do not know if it is exactly what you expect as an answer, but it is definitely worth the read.
Add a thread sleep at critical points. With each passing version, reduce the delay.