Context: I have a Google Spreadsheet with some data imported from the external API + some calculations done. API access + calculations are done using Google Apps Script. All those functions are within two files that belong to one project. Today in the morning I noticed multiple
Exception: Service invoked too many times for one day: urlfetch. errors. Strange enough, as neither I nor the second collaborator was working overnight. When I checked executions, it turned out there were multiple executions over the night. It looked as if the document was refreshed every 20-30 minutes.
Questions
How can I check what triggered those functions?
Any ideas how to prevent those executions?
Related
I have a container-bound Apps Script Project contained to a Form Response Google Sheet, triggered on form submit. The script runs as me. I'm dealing with execution runtimes 6-8x the nominal run time during peak hours of the day, which seems largely correlated to increased traffic of form submissions. The program follows this series of steps:
Form response collects a string of information and triggers the Apps Script Project to execute
Project creates a copy of a complex Google sheet of a few tabs and a lot of complex formulas
Project pastes the string collected from the form response into this google sheet copy, flushes the sheet, and then returns a string of results calculated within the sheet
Google sheet file is named and the Project creates a unique Drive folder where this sheet eventually gets moved to.
Run complete
The Project performs a wide variety of getValue and SetValue calls throughout the run as it's updating cell values or reading calculated results. Over the last year, I've improved optimization in many ways (i.e. batch calls to getValues or setValues, batch API calls, etc). It's normal run time is 25-45 seconds, but increases to 200+ seconds during my company's peak business hours. Using logs, there is no one particular step that gets hung up. But rather the script lags in all aspects (When it creates the file copy, SpreadsheetApp.flush(), append or delete rows in google other sheets it references by Sheet ID, etc). Although, I'll say a common reason for a failed execution returns the error message "Service Spreadsheets timed out while accessing document with id..." But most of the executions complete successfully, just after a lengthy run.
It seems there is a clear correlation between execution time and traffic. So my questions are:
Can anyone confirm that theory?
Is there a way I can increase the service's bandwidth for my project?
Is there a better alternative to having the script run as me? (mind you I'm performing the rest of my job using Chrome throughout the day while this program continues to automatically run in the background)
This is an Apps Script managed project; it is not tied to a personal GCP Project. Is that a potential factor at play here?
I have experienced a case where a Google Apps Script that moves data from one Google Sheet to another Google Sheet, is not pulling the current data in the sheet. I can verify this by checking the Version History in both sheets.
The issue occurred when the script ran from Google Trigger. Though I could not replicate when forcing the script.
I recorded a video to explain the issue:
https://drive.google.com/file/d/1HChy4WOR5ehg8EA6rlmvSH7Lqjg9bd30/view?usp=drivesdk
As the issue of "pulling old data", is only occurring on ~50 rows. And these are all items that we recently edited. So, that tells me that instead of pulling the "current data" in the sheet, Google pulled some "cached version of the data" instead (i.e. data from a few days, or week before).
I also experienced the same type of old data / caching issue with "IMPORTRANGE" formulas last week. Though this is first instance I have encountered the issue from a script.
This problem has me very worried, as I have setup many business systems to run on Google Sheets and Google Apps Script and rely GAS scripts moving the current/up to date data... for obvious reasons.
I am business owner, not a developer - but I would bet that Google has changed something in recent weeks relating to 'caching of data in Google Sheets'. I have tried reaching out to Google Workplace support to raise this issue but they don't seem to care, and they don't offer any support for GAS.
Hopefully others have this issue and we can get Google to resolve. In the meantime, I have to start preparing for a move away from the unreliable GAS and Google Sheets. Airtable is what I will be looking at firstly.
I just came across this same issue with a script of mine. It pulls cached data for about 4 minutes, then updates to the live version, then repeats that for the next few runs.
For my script in particular, I solved it based on an answer I received here: Script Pulling Cached Data. I set the text value "Running" to an empty cell on the source sheet at the start of the script, then flush, then delete that value from the dummy cell at the end of the script. Forcing it to write to the source tab seems to force the script to pull live data. It's been working consistently for a few hours now, so I believe this is a viable solution.
I hope this helps!
On my paid Google account, I have a lot of sheets using various scripts to fetch urls. I know there is a daily quote of fetches set, but the issue I have is that even if I don't open any of my sheets with scripts for over 24 hours, and then I open one, I get the over quota error message: Service invoked too many times for one day: urlfetch. I wouldn't have thought scripts would be running in the background, ie. without me opening them, but I can't explain this in any other way - does anyone know if this is so? Another way to put the question, how can I avoid getting such error?
Do you have any time based triggers set up for other scripts?
You can check by going to script.google.com and selecting My Triggers on the left hand side. Some of you scripts may be set to run even if you are not present.
I am trying to build a Google Data Studio Connector, but I am facing a Google Apps Script timeout issue for UrlFetchApp.fetch(). Is there any way we can extend it or fix it, because it is breaking our reports.
It happens due to multiple calls to our API simultaneously.
is your script running for more than the typical 30 minutes allowed? I had a UrlFetch situation where the order of arguments impacted how long it took to run the script. And by modifying the order, we got our script to run in 2-3 minutes instead of timing out.
I've spliced together a script which runs on a 1-minute interval and does a look-up on a Google label:
var mailthreads = GmailApp.search('label:MYLABEL');
Initially, the script ran fine, however within a few days the script began to throw a variety of errors, such as:
Service invoked too many times for one day: gmail
Service using too much computer time for one day
Service invoked too many times in a short time: gmail rateMax. Try Utilities.sleep(1000) between calls.
I have checked Quotas for Google Services with no real explination on what could be causing the script to fail - it ran initially day-to-day without fail, and as the cycle for quotas is 24-hours I would imagine if one 24-hour cycle worked, why didn't the rest?
One theory I have is that the GmailApp.Search query counts each returned item under the label as a single read, and now that the label has grown in size I am reaching a quota limit on reads. Is this how it works, and if not is there anything else I can check?