Here's the function, edited for brevity.
```
TwitterCredentials.SetCredentials(AccessToken, AccessSecret, AppKey, AppSecret);
...
usr = Tweetinvi.User.GetUserFromScreenName(userName);
...
_stream.AddTrack(track, (t) => this.IncomingTweet(evt, t));
_stream.StartStreamMatchingAnyConditionAsync();
```
So way down in GetTwitterQueryParameters it builds an ITwitterQuery object. This is the same route it followed successfully for the repeated calls to GetUserFromScreenName when the credentials were still intact. But then when I get to the StartStream* call, it has somehow lost part of the credentials. Again, this isn't even switching threads, it's just later in the same function. Before my hack, it would check the (_credentialsAccessor.CurrentThreadCredentials == null) and just throw an exception which was swallowed in all the anonymous function handlers somewhere. This meant the StartStream* call returned and ExceptionHandler.GetLastException() returned null as well. So it looked like it worked, but no request was actually generated. I changed it to check if the ApplicationCredentials existed and use those if they did. This happens to work for now.
```
if ( _credentialsAccessor.ApplicationCredentials != null ) {
_credentialsAccessor.CurrentThreadCredentials = _credentialsAccessor.ApplicationCredentials;
twitterQuery.OAuthCredentials = _credentialsAccessor.CurrentThreadCredentials;
}
```
Obviously, there are some other issues in here and this is just sort of patching the symptoms. In reality there's too many layers going on and there needs to be a way to pass the credentials along for more precise control and multi-threaded usage.
BTW, I did try wrapping this in a TwitterCredentials.ExecuteOperationWithCredentials just to test and it had no effect.
It would be better if the APIs took credentials as part of their calls so consumers can pass these around and use them more precisely instead of buried in statics and local variables. I think the same it true of the error handling. I've never found swallowing errors or creating code that can silently fail to be a good idea. Especially not for an API. As I consume it, I should really be aware of the consequences of each request. It makes everything easier to debug and more transparent.
Just my thoughts. Hope it helps.
Comments: ** Comment from web user: linvi **
Hi,
First of all this is a bug, that I will do my best to fix. Though I am not sure this is a multi-threading issue because as you said, you are losing your credentials in the same thread.
Please try the following DLLs and let me know if this allowed you to resolve your issue.
[Tweetinvi 0.9.8.0.Pre-Alpha - Binaries.zip](https://www.codeplex.com/Download/AttachmentDownload.ashx?ProjectName=tweetinvi&WorkItemId=2566&FileAttachmentId=3399)
Concerning your points regarding the API and how it is developed. I kind of agree with you, and in fact Tweetinvi before 0.9 required developers to pass credentials and other information around foreach of the query they wanted to use.
Now I had 2 choices, either lose some flexibility and not allow developers to pass the credentials OR make the code easier to read and more accessible to novice developers.
I decided to take the second route. Obviously I am trying my best to empower developers to have more control over the WebRequests and this is something that I will attempt to improve in the future releases.