I have code that was working fine when run in a single thread environment. I moved it to be a Windows service and suddenly the StreamMatching wasn't firing anymore. It is one single function in which some elements worked but the StreamMatching failed. After debugging I found that the credentials were being partially lost somehow.
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.
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.