Status Update
No update yet.
Comments
sa...@gmail.com
The ToT dependency was coming from compose:test-utils. Jeremy raised aosp/2254837 to pin this to a prebuilt.
Alternatively, we could have added explicit androidTestImplementation dependencies on ToT to ensure it's available during dependency resolution.
TL;DR If we express a constraint on androidx.thing:thing:$TOT_VERSION which maps to the tip-of-tree version for :thing:thing, then any occurrence of androidx.thing:thing:$VERSION where the constraint is present must also include :thing:thing somewhere in the transitive dependencies.
va...@google.com
My understanding of this issue is:
-
Project A's library code depends on prebuilt B.
-
Project A's test depends on prebuilt B and also library C.
-
Library C declares a constraint saying that B must be the same version as Library C.
-
When resolving dependencies for Project A's tests, these tests depend on prebuilt B and library C, so library C's dependency information is also considered.
-
Library C says it requires B of the same version.
-
To reconcile:
- these requirements:
- the dependency on prebuilt B
- the constraint for B to match the version of C
- Gradle looks for a prebuilt of B with version matching C.
- these requirements:
-
No prebuilt of B exists with the same version matching Library C, so Gradle fails to resolve the dependency.
Is this right?
The request in
am...@labnol.org
No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.
Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.
Assuming we're aligned...
Yes however if library B (e.g. project("B")) exists in the set of dependencies and its version matches C, then Gradle will successfully resolve the dependency by "upgrading" prebuilt B to library B.
ry...@gmail.com
No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.
Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.
Yes! Fixed, thanks
to...@xebia.com
The request in
is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different b/146802533
Slightly different. Fixing
Given that this was caused by tests using different dependency versions than the library's runtime dependencies, though, maybe this is broken-as-intended? The fix that Jeremy implemented was to pin the tests to the same version.
ro...@gmail.com
Marking as Fixed even though the general problem can still occur. Unclear that we need a systemic fix.
ru...@nexource.ro
We were able to track it down to a web service call that in turn calls DocumentApp.openById(..).
Is there an update on resolving this or an ETA, please?
ci...@hunton-lewis.com
Best regards,
[Deleted User] <[Deleted User]>
Experiencing this as well. The offending line according to the 500 response is var blob = DriveApp.getFileById(fileId).getAs('application/pdf');.
ke...@magentahealth.ca
var doc = DocumentApp.create("Temporary Document " + (new Date()).getTime());
As reported by others, it's only when this line is called via DoGet, when testing via the IDE, no issues.
ry...@gmail.com
ru...@nxr.ro
Needless to say this is causing production issues for our clients.
Again, is there an ETA for resolving this?
This has been going on for 3 days now - that is a lot by any standard.
Thanks
va...@google.com
Hello, did you authorize the web apps first after deployment? I can't reproduce this issue, however I have forwarded this internally. And will keep you updated here.
Kind regards,
ro...@gmail.com
even after providing authorization.
On Thu, Dec 17, 2020, 7:51 AM <buganizer-system@google.com> wrote:
ru...@nxr.ro
[Deleted User] <[Deleted User]>
Can confirm that switching to the V8 runtime fixes this.
bp...@panimex.cl
fo...@macombgov.org
Narrowed it down to this line of code: var copyId = DriveApp.getFileById(docTemplate).makecopy('new filename here').getId();
The code was written with the older engine. I tried converting it to the new v8 runtime. It did not solve my issue but did change the behavior slightly in that I can use different browsers but must be logged into a Google account in that browser window.
POSSIBLE TEMPORARY WORK AROUND
I have several apps that are being affected by this. What I have found is that if you are in the IDE OR if you are logged into a Google account, my apps will run correctly. I have tested this on Firefox, IE, Edge and Chrome. This is after migrating my code to v8.
mi...@macombgov.org
If I use any other browser OR if I am not logged into a Google account, I get the same error " We're sorry, a server error occurred. Please wait a bit and try again."
Narrowed it down to this line of code: var copyId = DriveApp.getFileById(docTemplate).makecopy('new filename here').getId();
First appearance of the errors was on 12/14/2020 in the morning. In the afternoon, it appeared to work. By morning of 12/15 it consistently failed.
The code was written with the older engine. I tried converting it to the new v8 runtime. It did not solve my issue but did change the behavior slightly in that I can use different browsers but must be logged into a Google account in that browser window. This app was deployed to run as me and accessible to anyone including anonymous.
POSSIBLE TEMPORARY WORK AROUND
I have several apps that are being affected by this. What I have found is that if you are in the IDE OR if you are logged into a Google account, my apps will run correctly. I have tested this on Firefox, IE, Edge and Chrome. This is after migrating my code to v8.
ru...@nxr.ro
4 days and counting now. No resolution, no ETA. Is there an update at all, please?
Migrating a couple of large apps to V8 overnight is not an option for us.
Also, as suggested above, that is not a fix.
Really eager to see how this unfolds, as quite frankly our clients are losing faith, very hard not to empathise with that given the circumstances.
Regards,
va...@google.com
Hello, I have forwarded this issue internally. As soon as I have any updates or ETA I will post it here. Please bear in mind, many of the reports on this thread are referring to different methods, none of which I could reproduce. Please also note that this is a public issue tracker and some of you may be experiencing issues which are related specific projects and not the products itself. Please
Kind regards,
ru...@nxr.ro
Here you go - this is a very specific report that can be reproduced with the provided scripts and two well defined use cases:
We also received an update stating this issue has changed - it now refers to an internal issue blocking it - can you elaborate - as the URL is blocked to us with an access denied message:
>Changed
>blocked by (+): 175934925
Thanks,
va...@google.com
Thank you creating a new issue for a specific method, it will be triaged right away. The "blocked by" issue is not visible publicly, it is meant for internal use.
to...@xebia.com
Is it possible some cache on your side or different code base on the different region?
To reproduce this issue is pretty simple. I already shared the drive with code on my first post. You must publish & deploy it as web app and not using V8 runtime.
You can call using CURL eg : curl -L <web app URL>
Or you can refer example from the previous comment which seems easier
I hope you can looks it seriously, it's really frustrated as several live projects unable to generate reports because of this issue.
ru...@nxr.ro
The secondary ticket I have opened pretty much confirms the statements of my fellow user to...@gcompany.nl - it definitely breaks as described with the Rhino engine.
>Please contact support directly if you wish to look into specific scripts which are failing
I just did that and I've been advised that they can't help, as Google Apps Scripts are not covered by Google Workspaces support.
They referred me back to you.
Apparently no way get proper support coverage for Google Apps Scripts?
To summarize, and I apologize in advance for being blunt:
- issue was reported by to...@gcompany.nl 4 days ago, confirmed by 17 users and growing
- it has started at the same time as Google had a world wide outage related to authentication systems, our issue appears to be related to authentication or lack thereof
- no visible action in 4 days, we're still going in circles and being referred back and forth
Is Google Apps Scripts a platform that we continue to use and recommend to our clients in good faith?
PS: After writing this message I can see my addition ticket being picked up and replicated - thank you for that:
From what I can tell, it is a clone of this ticket.
My question regarding the viability of the Google Apps Scripts support model stands, as I believe it is a legitimate one.
[Deleted User] <[Deleted User]>
var temp = DocumentApp.openById(ID);
This line breaks the code and return the error in the description.
Please, how can i solve this?
Thanks.
Alejandro
fa...@kettering.edu
mi...@macombgov.org
In my instance, I was able to upgrade all of my app scripts from the Rhino
runtime to the newer v8 runtime engine. Then compile the code to a new
version number. This appears to have resolved the issue for us.
The issue is not a browser issue as I originally thought. The issue is an
authentication issue with anonymous users and the Google Drive API. If the
user accessing your app is logged into a Google account in the same browser
that is running the app, in my instance the app will run properly. If they
are not, the app will appear to run correctly until the Google Drive API is
called. This is when the App Script will fail and return the server error.
It appears to affect only the Rhino compiler/runtime.
Hope this helps.
On Mon, Dec 21, 2020 at 7:27 AM <buganizer-system@google.com> wrote:
--
*Michael Whitacre*
Technology Liaison
16th Judicial Circuit Court
40 North Main Street, 6th Floor
Mount Clemens, MI 48043
Phone: 586-493-5741
E-mail: michael.whitacre@macombgov.org
Web:
PRIVACY NOTICE: This message is intended only for the individual or entity
to which it is addressed. It may contain privileged, confidential
information, which is exempt from disclosure under applicable laws. If you
are not the intended recipient, please note that you are strictly
prohibited from disseminating or distributing this information (other than
to the intended recipient) or copying this information. If you have
received this communication in error, please notify me immediately by the
email address or telephone number listed above. Thank you.
[Deleted User] <[Deleted User]>
Cheers.
au...@innovapad.info
va...@google.com
For those who don't have the option of updating due to their project restrictions, what specific Apps Script libraries are not compatible with v8? Are they yours or from a third party?
Best regards,
ph...@gmail.com
On Tue, Jan 12, 2021 at 5:22 PM <buganizer-system@google.com> wrote:
go...@google.com
Hi !
Thank you for providing that information. As this behaviour has been fixed I am closing this report. If you experience this behaviour again in the future please open a new report.
Best regards,
Description
If your issue has not been reported, please provide all of the following:
-----------------------------------------------------------------------------------------------------------------------------
A short description of the issue:
Keep getting "We're sorry, a server error occurred. Please wait a bit and try again." when try run web app URL (via postman or system)
What steps will reproduce the problem?
1. create a doGet method
2. ensure doGet call DocumentApp.openById function.
3. Deploy as web app and set execute as "me" and "anyone , even anonymous" can access
4. run the web app URL in postman.
5. Response show "We're sorry, a server error occurred. Please wait a bit and try again." .
Please provide any additional information below.
Sample code:
Sample web app URL :