Same error message and slightly similar to We're sorry, a server error occurred while reading from storage. Error code NOT_FOUND (simple onOpen trigger calling functions from a library), but in my case I had a web application. The solution from the top answer, to use a version instead of the head deployment, doesn't apply as my web app was already set to use a library version. The problem appeared after doing a slight change to the library.

1. The web app was working fine, but I was required to make a change.
   • My web app uses global variables to handle several settings.
2. I made a change to the library and created a new version
   • The change was moving a literal string from one array to another array.
3. I updated the library version number in the web app.
4. The web app works fine for my account but not for other accounts

• I reviewed the library version number in the manifest, it was OK.
• Using previous library versions works fine

The web app uses a Google Cloud Standard Project, set for internal use only. The library is used by other Google Apps Script projects. It has multiple namespaces (var myNamespace = ((ns) => { /** some stuff here */ return ns})({})) most of them are focused on using a single service (FormApp, SpreadsheetApp, DriveApp), but only few are used on the web app.

I wasn't able to reproduce the problem, so I think that it's related to the specific projects. Disabling V8 implies too much work i.e. I used a lot const , let, arrow functions and other stuff unsupported by the old runtime.

CodePudding user response：

Two workarounds solved the problem, none of them are "perfect".

1. Replacing the library by a copy (same code, different project URL / ID and version number)
2. Making a new web-app deployment (different web-app URL)

The main problem with the first is that I had to update other projects using the same library, the main problem with the later is that the new deployment has a different URL I had to notify the web app users the new URL, the might have to change their bookmarks / update their notes.

Finally I decided to use the second because there are other projects relaying on the library for sharing solutions settings shared through the library PropertiesService.getScriptProperties().