Fixed
Status Update
Comments
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #2
Converting to an enhancement request.
va...@google.com <va...@google.com> #3
Any update on the status of this enhancement?
va...@google.com <va...@google.com> #4
Fails for UrlFetches to far-away places like China. Making it configurable would be useful -- or reporting it as an actual timeout would help as well.
jb...@google.com <jb...@google.com> #5
I also need this feature, any update on the status ?
jb...@google.com <jb...@google.com> #6
Any update?
ap...@google.com <ap...@google.com> #7
Any update on this feature request, Its really important for us to have this feature
jb...@google.com <jb...@google.com> #8
I'm seeing the opposite issue lately. The UrlFetchApp.fetch call is taking far too long, the worst today is 257sec. I'd like to set a 10-30sec timeout and stop these calls from using up all of my time-based quotas. There must be an issue with this function as manually calling these urls is much faster, typically a second or less.
mo...@google.com <mo...@google.com>
mo...@google.com <mo...@google.com> #9
Yes, I need a configurable timeout to prevent a single long running fetch from eating up all the time-based quota.
mo...@google.com <mo...@google.com> #10
@ g...@websawin.com
I see the same bahaviour, that the timeout happens now after several minutes.
Also my UrlFetchApp.fetch() call aborted after more than 4 Minutes (!) today with an timeout!
According to the google error mail ("summary of failures of google apps script"), there must be also UrlFetchApp.fetch() calls taking more than 9 Minutes ("script exceeded maximum execution time").
This is consuming up all my daily CPU-time, very frustating :-((
I see the same bahaviour, that the timeout happens now after several minutes.
Also my UrlFetchApp.fetch() call aborted after more than 4 Minutes (!) today with an timeout!
According to the google error mail ("summary of failures of google apps script"), there must be also UrlFetchApp.fetch() calls taking more than 9 Minutes ("script exceeded maximum execution time").
This is consuming up all my daily CPU-time, very frustating :-((
ap...@google.com <ap...@google.com> #11
This would be a great feature, since max execution time for a trigger is 1h or 3h a day in pro plan and if a ressource doesn't respond it does eventually timeout after 5 minutes. It would be much better if we could timeout the request and try later to better optimize our ressources.
pr...@google.com <pr...@google.com> #12
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.transition:transition:1.5.0-alpha05
Description
Component used: Transition Version used: 1.5.0-alpha02 Devices/Android versions reproduced on: API 34
If you do a gesture back in Fragments using transitions and cancel the gesture multiple times, after the first cancel, starting the gesture will result in the transition on the exiting view failing to run.
I believe the cause of this is that the this
beginDelayedTransition()
called by with a 0 duration called by Fragment never triggersonAnimatedEnd()
callback inVisibility
. That results in the visibility failing to be added removed from the overlay and so the subsequent transitions on the view do not run.Here are logs synced with the calls from Fragment and Visibility. I would expect there to be an
onAnimationEnd reversed=false
log before theonTransitionEnd
in Visibility.The can be reproduced by patching in aosp/2748867 and doing the following in the navigation-integration app :