I am currently creating and deploying a function to be executed periodically in the Cloud Functions for Firebase scheduler as shown below.
The key point is that I want it to be executed every day at 0:05 Japan time as .timeZone('Asia/Tokyo').
The deploy itself is working fine, but when I look at the content in GCP's Cloud Scheduler, the Time Zone is set to (America/LosAngeles) as shown in the image below, and the actual execution time is off from Japan time.
I manually changed the time zone to Japan time in the Cloud Scheduler function management screen and confirmed that the desired behavior was achieved, but when I deploy the function again, it is still set to (America/LosAngeles).
I thought it might be affected by the region of GCP itself, and that I would have to change the region of GCP, but I haven't found where I can change it from.
However, I thought that I should be able to specify the .timeZone for each function from the code. I'm at a loss.
I don't know how to solve this problem, and I'm wondering if anyone can help me.
exports.XXX = functions.pubsub
.schedule('every day 0:05')
.timeZone('Asia/Tokyo')
.onRun((context) => {
///省略
});
Thank you in advance.
I have experienced the same problem too. There's also a similar question asked here and the solution to downgrade the firebase-tools works for me.
This could be related to your CLI version, Make sure it is updated and if you keep experiencing issues, you should contact firebase support to submit a bug request HERE.
Another solution is that the region could be set as undefined inside your Google Cloud Platform (GCP) resource location.
Just be warned that setting the GCP location isn't recommended unless you know what you are doing and you want to set all your default locations.
Reference: default-cloud-location
firebaser here
It looks like there is a bug in version 9.12 of firebase-tools that forces all Cloud Functions to be deployed in pacific timezone, regardless of the timezone you set in the code.
Upgrading to version 9.12.1 should fix the problem. For further details on the problem, see this issue on the Github repo.
Related
Prior a week from today, I had code that was working fine on Firebase Cloud Functions.
I've tried numerous solution to debug the problem but have run into this wall every time my code is activated:
{"errors":[{"code":20,"message":"Authentification key is not active"}
{"code":21,"message":"No permission for this authentication key"}]}
One solution had changed this error code into another:
{"error":{"code":403,"message":"Identity Toolkit API has not been used in project xxxxxx before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/identitytoolkit.googleapis.com/overview?project=xxxxxx then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.","errors":[{"message":"Identity Toolkit API has not been used in project 818729994826 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/identitytoolkit.googleapis.com/overview?project=xxxxxx then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.","domain":"usageLimits","reason":"accessNotConfigured","extendedHelp":"https://console.developers.google.com"}],"status":"PERMISSION_DENIED"}}
Which leads me to believe that this is authenticated related even though the code is hosted in a Google domain which I assume should be automatically authenticated.
Okay. I found the source of my error and the log response is not from Google but from my own code.
I am working in a team and it is without my knowing that one of my member of my team made some changes (unfortunately this is the environment I am working on so no git or mention what changes is happening).
Procedures to come to this conclusion is akin to disabling one plug-in at a time in Wordpress.
I broke my code apart in pieces and ran them and they ran perfectly fine. Until I came across a code that was talking to api and therefore spitting out this error.
Hope that helps anyone going through some big unknown in error debugging. Also, probably a nice caveat to learn unit testing.
We are setting up a new version of our app and we are switching from the legacy (v4) GTM SDKs to using the v5 mobile Google Tag Manager via Firebase.
On Thursday and Friday morning I ran some extensive tests on our tracking setup on Android and found a number of bugs in the GTM setup. I fixed them and then republished the app around mid-day on Friday.
On Monday morning (yesterday) I ran some additional tests and none of the fixes that I made worked, in the sense that the data that reached Google Analytics (the ultimate endpoint) showed the same errors from the previous round of testing.
My only conclusion is that the container didn't automatically update over the weekend (according to this, it should update every twelve hours).
I am pretty certain that this is the problem because some of the fixes included updating lookup table variables (we don't pass event category / event action as parameters from the app, these are mapped via two separate lookup tables), and the event category / action values were unchanged in GA in the second round of testing, even though they had been altered in GTM in between.
The documentation is a bit vague on exactly how the update process works - is there a way to debug exactly how to set up GTM in the app to ensure that it will automatically update when the container is republished in the GTM UI?
OK, the answer was pretty simple in the end, but as far as I can tell this is written nowhere in the documentation.
So, all you have to do is not rename the JSON file that you download from the GTM web interface - that's it! Our Android devs had renamed the different versions as gtm_dev.json, gtm_test.json, gtm_prod.json, etc, and this caused the automatic update to fail. That's it!
So if you are googling this error, double-check that your JSON file in the app has not been renamed.
I've been working on a game using Google VR in Unity3d and I recently updated my version of unity3d and the (built in) Google VR SDK to the latest version. After doing so the pre-launch report (automated testing on firebase) is showing crashes, during the unity splash screen, on 5 out of 6 devices.
This is the issue that is reported:
Issue: Crash of app uk.co.softkitty.puzzleroom running instrumentation ComponentInfo{com.google.android.apps.mtaas.crawler/android.support.test.runner.AndroidJUnitRunner}
Not very helpful, it looks like a generic unit test result if the app closes unexpectedly . I've looked through the logs and cant find anything unusual from my app or unity, but I did find something. It looks to me like this may be being caused by the test script itself:
10-27 01:54:54.494: I/ViewInteraction(19677): Performing 'single click' action on view (with class name: is "android.widget.ImageButton" and with id: uk.co.softkitty.puzzleroom:id/ui_back_button ...............
This to me, looks like the test runner is exploring the app UI and the first thing it does is click the "back" button. Which I would expect to close the app. I also tried using Firebase directly, which seemed to confirm it:
Firebase Activity Map
Does that seem likely that this is just a bug/red herring caused by changes to unity/GVR Or even firebase? Has anyone else experienced this?
I just don't want to release it if it really is crashing on so many devices!
Many Thanks
I asked Google Play Support about this and they got back to me.
They have confirmed that the issue is caused by a new crawler used by the Pre-Launch report. Details can be found here under the section "Pre-launch report versions"
They've escalated the issue and have also provided a workaround:
Sign in to your Play Console.
Select an app.
Select Release management > Pre-launch report > Settings.
In the “Pre-launch report version” section, move the Opt-out switch
to the right until it turns blue.
I haven't verified this yet but will mark as answer once I have.
Edit
I have tested this and all the tests pass again so this looks like a good solution for now.
We got this when uploading our APK as well. It started October 27th and crashed the following 4 days until we changed our setup. I couldn't see anything in our code base that should trigger this problem, so I wonder if it's related to changes on Google's side.
However, we did just did two changes and now everything's working again.
We added the following line to proguard-project.txt:
-keep class android.arch.** { *; }
I assume this was what fixed it.
At the same time we changed the compileSdkVersion and targetSdkVersion to 27 (and correspondingly all belonging support libs). For all I know they could have fixed it here too..
Edit:
To more directly answer your question: Yes, it does seem likely that this is just a bug/red herring, not on Unity's side, but in Firebase Test Lab or in Google's support lib. I tested the APK that failed the pre-launch tests and it worked just fine on my device.
I followed this link - https://developers.google.com/tag-manager/ios/v5/.
I can see my events in firebase console but not in google analytics.I defined my custom as well as default apple logevents.As it is also coming in my console "[Firebase/Analytics][I-ACS023024] No data to upload. Upload task will not be scheduled". I am using xcode 8.3.2 and swift3.Please help if anyone implemented.
There could be a few issues that can cause this. And more information is needed to find the cause, best place to look is the debug console in xCode.
GTM container is not setup correctly.
GTM Tags are not setup correctly.
The App/SDK checks for newer versions of the GTM container in 12 hour intervals. So if you did run the app for testing with a container with no tags, then added the tags to test for GA input, then the new container will not be used, until it gets the new container 12 or so hours later. (Work around for me was to uninstall the app from the simulator and run it again in xCode, just to be safe I clean the code too before running again. I did read somewhere that there was code to always check for newer containers, but I never got that to work)
Would be good if you can provide more information from the xCode debug console.
Update: The problems passed for a while, but then returned with a vengeance since yesterday. Deploys now really take forever and always fail with Server Error. connect ETIMEDOUT or Upload Error: Cannot read property 'response' of undefined or something else.
After experimenting with connecting via a US location using HideMyAss I found that that completely resolved my issues though! Note that this issue not only occurs when deploying from our office in Amsterdam, but also from our office in Rotterdam. In the meanwhile I have also heard from more people experiencing issues with other Google services.
I have replied to the related Firebase Support email with this information and hope they will look into it. In the meanwhile I guess I'll have to keep on using HideMyAss..
--
Deploying Functions has been taking increasingly longer times after adding more of them. Occasionally at first, but recently for some periods every time I try to $ firebase deploy --only functions one of the functions being deployed at random fails with:
⚠ functions[foo]: Deploy Error: Failure in the
execution environment
When I try again an hour or so later it deploys without a problem (still takes 2 minutes to deploy which seems a little slow).
Perhaps the deploy process is timing out; it always fails after a long time, never quickly.
Perhaps my location outside of America is resulting in latency related issues in the deployment process? Doesn't seem very likely though..
I'm also looking into Firebase Functions logging "Function execution took 60002 ms, finished with status: 'timeout'" and other performance issues, so I wonder if these are all related.
PS: I also reported this to https://firebase.google.com/support/ but the last report I made there is still un-answered after 15 days, so I'm going to go ahead and post it here as well. I included a firebase-debug.log with that report, but rather not publicly sharing that here (not sure if there any tokens in there etc).
Also having issues
I have been having similar issues today and I am deploying from the United States.
For example a function will fail showing these two errors:
Deploy Error: Failure in the execution environment
Error: Functions did not deploy properly.
I found that once when this happened it was because my internet connection was dropping and then totally dropped during a firebase deploy.
Then again it happened because I was trying to deploy at the exact same time that at lot of my cloud functions happened to kick off doing stuff on their servers.
Once the cloud function had failed, then even when my internet resumed and my functions weren't busily running, it would not let me redeploy to get the jammed function running again. No matter what the broken copy of it was stuck in their servers with the tag:
Failure in execution environment
My Solution
I found that once you have a problem like that you can actually rename the function. On the next deploy it will effectively delete the old broken function and reload it as a working copy with the new name.
I would think if your project required it to have the same name you could do this process one more time, deleting the copy with the new name and restoring the copy with the name you needed. Or even block commenting out the function to delete it on the first deploy and then uncommenting it on another deploy to reinstall it.
How that helps you
I'm hoping that if you are still having issues from the Netherlands it is helpful to know that it may be a slow connection issue or a busy server issue. As I have found these two things to cause problems for me from within the States.
Also my solution of deleting and redeploying the function might help to speed up a deploy if the issue is with a copy that is on their servers. It would be interesting to know if that helps because even though the function looks ok on the server maybe it had issues during the previous deploy that are jamming up future deploys.
Sorry for the late response to this, hopefully you are no longer having these issues with firebase (I hate firebase btw, always issues like this).