I am trying to add some telegram functions to my winForm app. I am using TLSharp library for that. However there is no proper manual on how to logout from the account. Everything I found on forums led to this:
var LogOut = new TLRequestLogOut();
await MainWindow.client.SendRequestAsync<Boolean>(LogOut);
That does log out but, 1st - It gives an Exception error:
System.InvalidOperationException: Couldn't read the packet length at TLSharp.Core.Network.TcpTransport.<Receieve>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
2nd - The "IsUserAuthorized" still return true after logout request.
3rd - session file, even being deleted with
File.Delete(sessionName);
restores itself
Related
Everytime I stop the program and rerun again the error message pop
PX.Data.PXException: API Login Limit
at PX.Api.ContractBased.Soap.WebApiSoapController.Post(ISoapSystemContract systemContract, XmlReader requestReader, String serviceNamespace, String internalNamespace, MethodInfo method, Func1 serviceFactory, IEdmModel edmModel)
at PX.Api.ContractBased.Soap.WebApiSoapController.<Login>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Threading.Tasks.TaskHelpersExtensions.<CastToObject>d__31.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ApiControllerActionInvoker.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ExceptionFilterResult.d__0.MoveNext()
this is my code on log in
...
using (DefaultSoapClient soapClient = new DefaultSoapClient())
{
//Log in to Acumatica ERP
soapClient.Login
(
Properties.Settings.Default.UserName,
Properties.Settings.Default.Password,
Properties.Settings.Default.CompanyName,
Properties.Settings.Default.Branch,
null
);
...
try
{
...
soapClient.Logout();
}
catch (Exception e)
{
...
soapClient.Logout();
}
finally
{
...
}
what's wrong with my code and how do I fix it?
Unlicensed demo versions have a limited amount of API connection session available.
You have to make sure Logout is always called after Login otherwise you'll run out of available connection sessions. For unlicensed version you should aim for a maximum of 1 connection at any time and make sure the application can't be stopped without executing the API connection session logout.
Here's the stategy I would use to ensure that:
Use only single threaded code to interact with the API because you
want to avoid multiple concurrent connections when using unlicensed
version.
Wrap all code interacting with the API in exception block that will
always call logout. It doesn't hurt to be paranoid here, you can event put the login code in the try block because if login fails there's no harm in trying to logout.
Try to make your session short and to the point, don't login
pre-emptively or keep the connection opened for longer than required.
Having sessions hanging around for too long increases the chances of
losing the connection before you can issue the logout command or
simply forgetting to logout.
Register an application wide OnClose event handler to Logout of the
session when the user soft closes the application. If the user hard closes the application (ex: by killing it with task manager) you can't execute logout so you'll have to wait for the session to expire or restart IIS to avoid API connection limit exceeded errors.
Log each connection login/logout attempts to disk (whether successful
or not) to make sure it always calls logout for each login. When
login is executed create a unique id for that connection and log it,
when logout is executed log it with the same unique id. If you get
the API limit error again you'll have log data to confirm whether or
not you have successfully logout of all opened sessions.
I have a bot that runs on Azure + Bot Framework + LUIS (via LuisDialog).
If the user happens to send two messages in a quick succession (before the bot has a chance to answer), they see this error message on their Facebook Messenger or web embed:
Sorry, my bot code is having an issue.
When debugging through bot channel emulator, I see that the error is this:
"text": "Error: Response status code does not indicate success: 429
(Too Many Requests). at
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task
task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task)
Microsoft.Bot.Builder.Luis.LuisService.d__4.MoveNext()
The end of the stack trace shows that the error originated at this line in my MessageController.cs:
await Conversation.SendAsync(activity, () => new LuisRootDialogEnglish());
This is weird because I'm using a paid version of LUIS which allows up to 10 calls per second.
In any case, I tried wrapping the whole code in MessageController.cs into a try/catch block, and returning this value regardless of an exception:
return Request.CreateResponse(HttpStatusCode.OK);
Still, the users see the error message "Sorry, my bot code is having an issue" which basically means there is an unhandled exception.
How can I prevent this message from being shown to users, or catch the exception?
The message is sent to the user in PostUnhandledExceptionToUserTask only because the exception has escaped the root dialog A. You can avoid this situation by preventing unhandled exceptions from escaping the root dialog A.
One option is to add a different root dialog B that simply calls your dialog A and then simply ignores the IAwaitable<R> result that is passed to the ResumeAfter<R> callback.
Chain.DefaultIfException provides an implementation of dialog B.
You can use DefaultIfException functionality for Bot Framework to internally handle the exception.
It looks like this:
await Conversation.SendAsync(
activity, () => new Dialogs.RootDialog().DefaultIfException()
);
When you get an 403 or 429, it could be "out of quota" or "Too many request" respectively, in the first case you must create a key again and asign to your LUIS App, the first-1000 endpoint queries are free and it will be refreshed every month, you must use it wisely or you have to use a Paid tier.
For the second case you have also a limit for the request, see the Boundaries documentation
Here you can find Microsoft documentation about this.
There is an odd exception in logs of my MVC 6 (beta 7) project:
01:29:55.8657 Error Flush
System.IO.IOException ---> Microsoft.Net.Http.Server.WebListenerException: The specified network name is no longer available
--- End of inner exception stack trace ---
01:29:55.8901 Error ProcessRequestAsync
System.IO.IOException ---> Microsoft.Net.Http.Server.WebListenerException: The specified network name is no longer available
--- End of inner exception stack trace ---
at Microsoft.Net.Http.Server.ResponseStream.FlushInternal(Boolean endOfRequest)
at Microsoft.Net.Http.Server.ResponseStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at Microsoft.Net.Http.Server.Response.Dispose()
at Microsoft.Net.Http.Server.RequestContext.Dispose()
at Microsoft.AspNet.Server.WebListener.MessagePump.<ProcessRequestAsync>d__23.MoveNext()
I have found such errors were outside the MVC 6 (the fist link, the second link)
But in my case a source of the exception is the Microsoft.Net.Http.Server.ResponseStream.FlushInternal method.
The error does not interrupt the application. It occurs after some queries (I did not notice a pattern), and is rarely.
Why this error occurs periodically in my log?
Can I do take any actions to avoid the error?
Thank you!
That sounds like the client disconnected before the response was sent. That can be difficult to detect without writing to the socket. We have a (private) work item to de-emphasize these error messages in the logs.
I have a Windows 8.1 app on the Store, but when I try to use the next piece of code for a new feature I want to add to my app
var listingInfo = await CurrentApp.LoadListingInformationAsync();
I receive an error which I don't exactly know what it means. I did catch the error though and I displayed it on a MessageDialog and then I took a print screen. This is the error:
We could not receive your donation due to an unexpected error:
System.Exception: Exception from HRESULT: 0x801900CC
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at ArchMedia_Player.Services.Donations.<ListingInformationAsync> d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at ArchMedia_Player.Services.Donations.<Donate>d__a.MoveNext()
Does anybody know what that means and how can I solve it ?
I also mention that this works perfectly ok: (using the CurrentApp Simulator)
var listingInfo = await CurrentAppSimulator.LoadListingInformationAsync();
System.Exception: Exception from HRESULT: 0x801900CC
That's an expected exception while you are developing your app. The error code is BG_E_HTTP_ERROR_204, 0xCC encodes the HTTP response error code. 0xCC == 204, HTTP error 204 means "No content". Or in other words, the Store server is not aware of your app having any in-app purchases.
This is a chicken-and-egg problem, the server doesn't know about your in-app purchases until after you submitted your app and got it approved. You must test your app with CurrentAppSimuator to debug and test your in-app purchases. The basic how-to guide is here. One important step you must not forget is to substitute CurrentAppSimulator with CurrentApp just before you submit your app for verification.
That your app is already in the Store does not factor in when you added in-app purchases to your new version. The crucial required step is to make the Store server aware of your purchase options. As described by the linked MSDN article, you do this when you submit the app. They will not be effective until your submission is approved.
So, do not panic, you can test your code with the simulator. When you've verified that you got that working, there's little reason to fear this being a problem after you submitted the app, as long as you follow the steps in the MSDN article.
I had same exception. I updated package certificate File (StoreKey.pfx), by creating package with sign in to the windows store. And it fix problem for me.
I'm getting this exception when awaiting LoginAsync:
await fb.LoginAsync("user_about_me");
The full stack trace is the following:
{System.InvalidOperationException: Operation is not valid due to the current state of the object.
at Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FacebookServiceClient.FbServiceClient.<Login>d__0.MoveNext()}
I'm using Facebook Client 0.5.0.
The strange thing is that this error doesn't always occur, usually when I start a coding session everything is just fine, but then (after a few debug sessions) this exception popups every time.
Any thoughts?
Edit: I have this problem even on the SDK github sample
The problem is not anything to do with the operation itself after browsing the code I found out that the problem is when the browser fails to connect to facebook this exception is thrown.