With regards to the test suite, I've entered the userAgentId and the json key correctly and it progresses fine. It's when I start the test where the problem arises. Each utterance is read out to my Google Home. The Google Home wakes up to the "Ok Google. Turn off the colorful light ". The colorful light are off and reported the close status to the home graph. I link to the reportstate dashboard to confirm quickly that the status has been modified. After I waited a long time and finally got a timeout error. I don't know why and what else I need to do? I have two screenshots here. One is the request timeout and the other is the reportstatus dashboard.
timeout pic
reportstate dashboard of my colorful light
Timeouts with the test suite can be due to the following reason:
--The execution or query responses might be failing, or taking too much time.
--Report State implementation might be faulty.
The report state dashboard is an old tool that is not maintained anymore, hence the changes you see there might not represent what’s written to the homegraph accurately. Instead, can you try out using the HomeGraph Viewer.
Related
We are using Azure Application Insights for a project, and I want to stop App Insights from detecting the same problem multiple times in a row, if it's the same piece of data causing the same issue repeatedly:
E.G when posting a data item to a third party API, the data is an incorrect format so the API will reject it, and an Alert will be flagged. The item will return to the top of the queue, only to attempt this again an hour later, resulting in continuous alerts unless the system is shut down.
I don't want to have to answer an alert at every hour of the day, and whilst I understand a code solution would be possible to resolve this, I am hoping that there is a simpler fix that can be made in Application Insights to prevent this from occurring in a more blanket solution.
My site works nicely as a PWA and I am trying to improve it. I have a couple of things going on and I am not sure if this is normal behavior or not.
Starting with offline.html. Right now I have a standard simple piece of text that say you are viewing example in offline mode. There is no header/footer or any other content. I'd really like to improve that but where and how much can I improve it? It doesn't seem to act like a normal page. I also find a problem on my child pages where when testing and looking at a waterfall chart, offline.html is coming back as a 404. I doubt this is normal.
Secondly, when I run a lighthouse test on a child page like example.com/childpage I get the following;
Current page does not respond with a 200 when offline
start_url does not respond with a 200 when offlineThe start_url did respond, but not via a service worker.
Does not register a service worker that controls page and start_url
I've tried to search for answers but I'm not having much luck. Any help or suggestions would be appreciated? Thanks.
I only understand from a VueJs perspective.
If your app isn't registering your service worker, then the service worker won't be able to intercept the http request, please see attached pic. basically you need to get that registered before you continue.
reference: https://www.sicara.ai/blog/2017-06-30-part-three-progressive-web-app-with-vue-js-webpack-material-design
you can add a <noscript> tag into your index.html which will catch when your JS doesn't load see: https://web.dev/without-javascript/
Going back to registering your service worker; You need to make sure your webpack, or like in my case my vue.config.js is actually registering your PWA correctly, including the service-worker.js
pwa: {
themeColor: '#2F1B55',
msTileColor: '#000000',
iconPaths: {
favicon32: 'static/favicon-32x32.png',
},
workboxPluginMode: 'InjectManifest',
workboxOptions: {
swSrc: 'service-worker.js',
},
navigateFallback: 'yourDir/public/index.html'
}
navigateFallback this is important to tell the browser where to start the JS from again when it falls over mid app.
Getting a service worker registered on build is your primary concern. Try reading the article from 1. to get a greater understanding.
Thanks for your input, I'll read tonight. That said,I can put my mobile device into airplane mode and my entire PWA acts just the way it did when I was online (unless its a DB lookup). This is why I'm a bit confused. Every page that I visited online is available offline. I only get these warnings from lighthouse. In devtools, there is no warning. Cheers.
I have built a google actions project and published it. It has a web hook that is linked to a Google Functions with an actions sdk code behind it. Everything works fine.
However, I have noticed that there is a continuous user (with the same userId provided by the intent) that keeps access the function (guessing via the actions project). I am keeping a kind of sessions log and it keeps creating a session almost every 3-4 seconds.
Since the project is just some temporary demo of content and not really shared with the world at large, I am wondering what or who is causing this continuous access. It looks almost like some heart-beat type of check being done. Hence the question: is it something that Google does to know whether the action project is live or not? Thanks
Every 3-4 seconds seems high, but if you have published an Action that has gone through the review process Google does run a health check against it every few minutes.
I'm trying to create a simple order using transactions API on actions on Google, for this, I'm using this sample app, but when I try to place the order, the device times out, instead of showing the receipt details. The weird thing is that this code gets executed (I added some logs locally to make sure).
Has anyone been able to run this sample app successfully? I already enabled the actions on Google API on my project on Google cloud, so I'm not sure what I'm missing here.
First, you got to make sure you have enabled transaction support for your app.
If you are testing on the simulator, disable Sandbox mode (checkbox on top right).
Sandbox ensures that any transactions or orders made during simulation are fake
I've ran into this issue before.
You have to keep in mind that the Order ID gets tracked so it needs to be different every time you run the app. That is why I decided to use a UUID time stamp function to make sure the Order ID will be different every time.
I'm referring to wherever it mentions 'UNIQUE_ORDER_ID' in the code. Once you take care of this issue, you will see the receipt every time you run the demo.
We couldn’t deliver this payload: Service Timeout
I was successfully sending webooks to my server 5 minutes ago, and now I just keep getting timeouts. I tried deleting the webook and re-adding it, changing the URL it points to, but nothing.
Am I flooding it with too many pushes, or is GitHub's webhook service just down?
It also turns out that GitHub has a 10-second timeout set on their webhooks. That is what I ran into. See the documentation here.
Unless there is some kind of error on the GitHub side (which doesn't seem to be the case at the moment, given their "System Status" history), you might check the program receiving the payload of that webhook.
See a similar problem in Supybot-plugins 225:
I contacted GitHub support and one of the employees has been troubleshooting this for me. Here is part of what he had to say about the issue:
I just tried making a request manually from one of our machines, and that went through with no error (see curl -v output below).
However, I did notice that it took extremely long for the request to be processed -- over 15 seconds (for 2 bytes of data).
Decoupling the listening and reception of the payload, from its proicessing, is generally the right approach, as I recommended ion "Perl Script slow over Tomcat 6.0 and generates service time out".
The first part should be as fast as possible.