I have integrated Raygun into one of my angular project and I'm also able to get some of the JavaScript related errors but not reference, syntax and type error on Raygun platform.
Though Raygun is not logging any xhr related errors on their platform. Got 403 Forbidden, 404 Not found and 500 internal server error on my network calls but Raygun did not reported any of those.
I have used the following steps for the setup:
Installed raygun4js package through npm using this command npm install --save raygun4js
Installed #types/raygun4js package through npm using this command npm i --save-dev #types/raygun4js
Added the following code
import { ErrorHandler } from '#angular/core';
const VERSION_NUMBER = '1.0.0.0';
rg4js('apiKey', "***");
rg4js('setVersion', VERSION_NUMBER);
rg4js('enableCrashReporting', true);
export class RaygunErrorHandler implements ErrorHandler {
handleError(e: any) {
rg4js('send', {
error: e
});
}
}
I have checked on their docs and different online available resources for xhr related errors but got no help.
What can I more use to get xhr related errors. In case, if it is not possible, let me know that as well. Also please do let me know if I can or cannot get JavaScript reference, syntax and type error, framework related and performance related error also as I'm not getting that as well on Raygun platform.
I have setup Firebase AppCheck for my Web App and everything seemed to work fine. Now I would like to enable the debug mode when developing my app.
I followed the instructions in the official documentation but I keep getting random errors from the AppCheck module, and these prevent my app from accessing Firebase Storage:
...at Backend FirebaseError: AppCheck: Fetch server returned an HTTP
error status. HTTP status: 429. (appCheck/fetch-status-error).
Following the doc, this is the way I set AppCheck in debug mode - this is ran before everything else:
if(window.location.hostname == "localhost")
self.FIREBASE_APPCHECK_DEBUG_TOKEN = true;
Again, when my app is not in debug mode it works just fine.
Note 1: that I am not enforcing AppCheck via the console, and that 100% of the requests are displayed as "Verified"
Note 2: googling for "Firebase error 429" shows many results referring to some quota being exceeded, something hardly possible for my dev environment (we are 2 devs and definitely not putting in any sort of load on the app)
Its a bug with the js library
https://github.com/firebase/firebase-js-sdk/issues/5052
You should be using environment variables to detect debugging mode or not.
Depending on your framework and setup, this could be a command that you set up in your serve/build commands or a local env file that contains a specific debug key.
There is another issue if your reCaptcha is set to use localhost as the documentation states:
Warning: Do not try to enable localhost debugging by adding localhost to reCAPTCHA’s allowed domains. Doing so would allow anyone to run your app from their local machines!
I have below issues with Express Gateway logs:
I have enabled Express Gateway logs according to their documentation, but I couldn't find any log file created under my gateway root.
When I start the gateway with below command it shows debug logs, but the changes that I do in gateway.config.yml config will not reflect in debug log.
LOG_LEVEL=debug npm start
How do I add timestamp for the log entries?
Edited:
gateway.config.yml config values:
pipelines:
default:
apiEndpoints:
- api
policies:
- log: # policy name
- action: # array of condition/actions objects
#timestamp: true
message: Test ${req.method} ${req.originalUrl} # parameter for log action
# Uncommentkey-auth:when instructed to in the Getting Started guide.
- key-auth:
- proxy:
- action:
serviceEndpoint: httpbin
changeOrigin: true
Express Gateway has no way to store logs on files. While this is technically possible (We're using Winston under the hood so we would just need to put the right transport strategy) we haven't provided a way to enable it. Right now you'd need to catch the log from the standard output and save them somewhere, using IO redirection in case you're on an UNIX system.
I'm not quite sure what you mean here. When you're doing some changes to the gateway.config file you should receive an info message telling you the hot reloading has completed. If you can elaborate more I can be more precise here
Unfortunately you can't. Our logging strategy is not exactly THAT configurable. It might be worth to open an issue on our repository so we can prioritize these requests.
Thanks,
V.
I am trying to integrate Sentry error reporting with my react app. I have it working with my backend fine, but I am now having issues with the frontend.
What I have found is that if I run the Raven.configure("sdn").install() from my webrowser console, the error logging will work.
I have added the the script & configure to my index.html, but it will not log errors without my manually configuring in the browser console.
Thanks
I'm trying to run socket.io and I'm getting a bunch of these:
http://domain.com:8080/socket.io/?EIO=2&transport=polling&t=1401421022966-0 400 (Bad Request)
This is the response I'm getting:
{"code":0,"message":"Transport unknown"}
I can't find any reason. I read somewhere that it might be misinterpreting the client, but that's about as far as I could get.
I had the same issue after upgrading from 0.9.x to 1.x.x. Shortening the long story, I would set transports to ['websocket', 'polling'] and then the error...
when you config your server to use specefic transpors you should set the same config on client side to...
server
var io = require('socket.io')(server, {'transports': ['websocket', 'polling']});
client
var io = io( serverUri, {'transports': ['websocket', 'polling']});
I had the same issue,after upgrading from 0.9.x, turns out my server config was set to ['websocket', 'jsonp-polling'] which was valid in 0.9 but the default config for the client and server is now ['polling', 'websocket'].
Removing my server config got me up and running.
The config is now documented in engine.io (https://github.com/automattic/engine.io), the new transport layer introduced in 1.0 - in particular this line:
transports ( String): transports to allow connections to (['polling', 'websocket'])
i had the same issue:
Getting the latest socket-client.js and using these file on clientside, solved this problem for me.
This happened to me when I served the socket.io.js script myself.
I had to go copy node_modules/socket.io/node_modules/socket.io-client/socket.io.js to where I was serving it up.
Try this configuration on server side
const io = require('socket.io')(server, {
cors: {
origin: "http://localhost:8100",
methods: ["GET", "POST"],
transports: ['websocket', 'polling'],
credentials: true
},
allowEIO3: true
});
My solution was to upgrade node.js to latest (0.12.0 at the time of this post). Originally node.js was installed as a part of a bundle. Once I uninstalled that node.js coming from that bundle (Aptana 3 bundle, node.js was somewhat behind), and installed the latest from node.js's website, things started working finally.
I was experimenting with React.js. I spent several hours debugging the phenomena, I've found build errors in socket.io, specifically about socket.io-client, it tried to invoke Visual Studio MSBuild unsuccesfully. Which is sad, the error occured with node-gyp too. Apparently socket.io-client is not needed to run/serve my examples, and seems like these unfortunate errors (which lured me into an endless forest) can be ignored.
(I noticed also a module while installing webpack-dev-server, which is Darwin only (a.k.a. Mac OS X). That's fortunately an optional dependency. It's frightening though: I know that Apple is very hipster, but the majority of the world is non Mac.)
I fixed it acting in my server.js
the io instance is initialized as follow:
const io = socket.listen(httpServer, { serveClient: true })
Before I had { serveClient: false }, because otherwise, I was getting an error. But actually, if you want that your client takes io from the node instance you have to serve it.
UPDATE: At the end.. you want to simply have const io = socket.listen(httpServer)
In this way is going to be true by default.