When I call Hub method I get frame response:
{"invocationId":"1","type":3,"error":"An error occurred while updating
the entries. See the inner exception for details."}
How can I get detailed error report (row and file where error occurred) without manually debugging and using step over and check where the code raise exception.
On net I found plenty codes where EnableDetailedErrors is used
services.AddSignalR(options =>
{
options.Hubs.EnableDetailedErrors = true;
});
but options (at least in version 1.0.0-alpha2-final) does not have property Hubs.
This is what you need to do in core (not sure the exact version this was added):
// signalR
services.AddSignalR(options =>
{
if (Environment.IsDevelopment()) {
options.EnableDetailedErrors = true;
}
});
It goes without saying that the reason this is disabled by default in production is for security reasons. So be careful not to expose things you may not wish 'hackers' to see in any of the exceptions you may throw.
Implementing the above setting will reveal a more detailed message in the browser console, whcih you can also see in the websocket debugging tab:
Quick tip:
I've set up SignalR twice now on ASPNetCore and I think I've made the same mistake both times:
// from typescript client arguments are passed like this
this.hubConnection.invoke('SendMessage', 'simon', 'hello');
// not like this
this.hubConnection.invoke('SendMessage', ['simon', 'hello']);
Also invoke will wait for a response, while send does not. So you may not see errors using send.
Currently the option to enable detailed errors is not implemented. There is an issue tracking this. My recommendation would be to turn on logging on the server side - the original exception will be logged there.
Related
I am trying to get simple auth in my Teams app working with Adobe ID (a third party Oauth provider that I use on my site).
I am following the sample here. Everything is working to authorize with the Adobe ID, but when it gets to my end authentication page like this, I get an exception thrown with the message "SDK initialization timed out." when I call await app.initialize();. The sample shown does not have the await term before app.initialize(). Is that incorrect? If I remove the await, my code later on to notify authentication of success, fails with the exception "The library has not yet been initialized".
authentication.notifySuccess("Yippee");
What do I need to do to allow app.initialize() to work?
How can the sample work if there is no await before it?
Here is the TypeScript code for my OAuth End page that is loaded after the Adobe Authentication succeeds.
import $ from "jquery";
import {app, authentication} from "#microsoft/teams-js";
startup();
async function startup(){
try{
$("#status").text("Initializing");
await app.initialize();
$("#status").text("Initialized");
console.log("notifying of success");
authentication.notifySuccess("Yippee");
}
catch(error){
handleError(error, "initializing");
}
}
function handleError(error:Error, context: string){
console.error(`💥 Error ${context}: ${error.message}`);
$("#status").text(error.message);
}
What version of the js library are you using?
There have been some changes to how app.initialize is handled depending on the version of the SDK you are using- see details here
https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/using-teams-client-library?tabs=typescript%2Cmanifest-teams-toolkit#callbacks-converted-to-promises
You should be able to see this in package.json for typescript, although I think there may be other areas where you may need to update this.
Try this with the version referenced in the sample- 2.0.0 does that resolve the issue?
re: await- that just tells the application to wait until a response is returned (a success or failure) before moving on to the next line. In your case, you need the await as your next line is dependent on the value of status, but your function is async, so it won't block the execution of other async functions. You want to use await where you have other requests that must have a response on that call- like getauthtoken.
Unhandled exceptions can only be logged in detail into audit logs when
SendExceptionsDetailsToClients set true. But exception should not be send to clients in production.
I don't konw why audit logging module can not get the exception detail,is it triggered by action filter? It runs after exception filer?
thanks for any help!
I solved the problem.As it is said in the question,SendExceptionsDetailsToClients is the key. I checked the source code and found that audit log also flows this setting.
Just custom a converter to repalce the AuditLogInfoToAuditLogConverter, and modify these 2 lines ,both set true.
//AuditLogInfoToAuditLogConverter.cs
var remoteServiceErrorInfos = auditLogInfo.Exceptions?.Select(exception => ExceptionToErrorInfoConverter.Convert(exception, options =>
{
options.SendExceptionsDetailsToClients = true;//ExceptionHandlingOptions.SendExceptionsDetailsToClients;
options.SendStackTraceToClients = true;//ExceptionHandlingOptions.SendStackTraceToClients;
}))?? new List<RemoteServiceErrorInfo>();
I'm having incredible difficulty setting up the Twilio Client in Meteor JS, and would really appreciate any help.
I have extracted the relevant code and error logs below. So far as I can tell, it should be simple. The code is just grabbing an authtoken which I have previously generated, and then trying to set up the device using that authtoken. But it's not working.
'click #initializeDevice'(event) {
var thisAuthToken = Session.get('myAuthToken');
console.log(thisAuthToken); // I have confirmed with Twilio support that these authtokens are correctly generated
const Device = require('twilio-client').Device;
Device.setup(thisAuthToken, { debug: true });
var myStatus = Device.status()
console.log(myStatus); //this is logging "offline"
Device.on('ready',function (device) {
log('Twilio.Device Ready!'); //this is not logging anything
});
},
When that code runs, it generates the following logs:
eyJhbGciDpvdXRnb2luZz9hcHBTaWQ9QVA2NDE2MzJmMzA1ZjJiY2I[Note:I have deleted part of the middle of the logged authtoken for the purpose of this public post]5YmMxOGQyOWVlNGU2ZGM0NjdmMzRiNDVhNCIsImV4cCI6MTU3Nz0ygbJKTx15GgNCWDkm-iUPjn_O1NZU6yovp4vjE
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Setting up VSP
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 WSTransport.open() called...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Attempting to connect...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Closing and cleaning up WebSocket...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 No WebSocket to clean up.
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Could not connect to endpoint: ws does not work in the browser. Browser clients must use the native WebSocket object
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Closing and cleaning up WebSocket...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 No WebSocket to clean up.
calltemplate.js:31 offline
I'm doing this all from a local server, tunneled through NGROK. I've also set up the Twilio back end, linked the app, purchased a number, etc.
So far as I can tell, the issue, from the logs, appears to be something to do with the way that Meteor uses WebSockets.
Could not connect to endpoint: ws does not work in the browser. Browser clients must use the native WebSocket object
This is a not a Meteor related problem rather than browser issue.
Make sure your browser supports WebRTC
BTW, Your browser might be supporting it but you'd need to enable it.
I'm using SignalR but have run into a problem. When a connection is started in one browser window and then a user logs in in another browser window the User identity is changed (this causes the error 'System.InvalidOperationException: Unrecognized user identity. The user identity cannot change during an active SignalR connection' on the server when a method is called on the hub.
I'm using this code on the client:
proxy.server.analyze(content)
.done(function () {
console.log('Success!');
})
.always(function () {
console.log('This is always called!');
})
.fail(function (error) {
console.log('This is never called!');
});
When I'm seeing errors on the server the fail function is never being called so there appears to be no way on the client to handle this problem and stop and start the connection.
So is there a "best practice" way of handling this case? How can I detect on the client that the user identity has changed in another browser window and stop and re-start the connection?
This is a known issue.
It is fixed in the next release. Here's the issue that ended up also fixing your issue: https://github.com/SignalR/SignalR/issues/2106.
Lastly, in the next release (0.2.0) what will happen is the connection will throw an error and stop itself. Therefore you'll be able to handle your case via either the error handler or you can of course you can tie into the "disconnected" event.
If you're willing to try a pre-releases you can always pull from the offical source or webstack nightly (http://www.myget.org/F/aspnetwebstacknightly/)
I have to implement some error handling logic for DynamoDb errors. As said by AWS documentation, the errors are divided into client and server errors.
May be I am missing something in the object browser, but I don't understand how I will retrieve the "HttpStatusCode StatusCode" for the client errors (AmazonClientException) ?
This is just part of the server errors (AmazonServiceException) only.
As, I need to do some logging based on the error code, it seems that it can not be obtained from client exceptions currently.
There is no status code for a AmazonClientException which is not also an AmazonServiceException. If you have one from the service, it will be of the second type and you can get the status code. If you have one of the first type, it could be because you don't have an internet connection, or the service responded with a malformed response (perhaps not even HTTP, who knows!).
It's a little confusing that they decided to extend AmazonClientException with AmazonServiceException, because it means that (in java) you might have to do something like this:
try {
// ... make some dynamo requests ...
} catch (AmazonServiceException e) {
// aha, I can get at the status code!
} catch (AmazonClientException e) {
// OK, something really bizarre happened... perhaps dynamo is
// down, or I'm having internet issues.
}