Unable to write Key to Redis.List - How to debug?

[dfdumaresq]

In our production netcore (v1.1.5 WebAPI + ReactJS) project, I'm unable to see the key we are using.

However in a sample netcore project (v1.1.5 WebAPI), it works fine.
Using redis-commander and docker we see:

redis-commander    | loading key ".NET Web Api" from "redis:6379:0"
redis-commander    | loading keys by prefix ""

In the our production project, we just see:

redis-commander    | loading keys by prefix ""
redis-commander    | found 1 keys for ""

In the controller I'm testing we're calling:

        string myKey = "netcore1";
        var log = new LoggerConfiguration()
            .WriteTo.Console(theme: AnsiConsoleTheme.Code)
            .WriteTo.RedisList("localhost:6379", myKey)
            .CreateLogger();`

And issuing requests from Postman to avoid working through the UI.

The production project is fairly large and tearing it down and testing seems pretty daunting.
Where would you suggest debugging the serilog.redis.list code?

[dburriss]

Hi @dfdumaresq
To be honest I have not looked at this for ages since we moved over to Splunk at work.
Next weekend I can try upgrade this to make it easier to work with in VS since it is still using xproj.
I didn't 100% understand the symptoms. If I understand correctly, nothing is being logged on production? By design the logging doesn't throw if configuration is incorrect since the logger sink being down is a poor reason to crash the application, and throwing and catching is pointless since logging is unavailable. A giant shot in the dark is that it doesn't like your production configuration or cannot reach Redis from where it is. As a starting point I would take a look at src/Serilog.Sinks.Redis.List/RedisLoggerConfigurationExt.cs and setup an action that sets up a connection like that with your setting but without the NoConnectionMultiplexer and instead just throw. The NoConnectionMultiplexer is what allows it to fail silently. Maybe I should put some Debug tracing in that.

Alternatively I would suggest pulling down the repository and creating an API project in the examples folder and referencing the project directly with an example.

[dfdumaresq]

Thanks for your reply, @dburriss.
I should say that I'm not 100% certain that this works in netcore 1.x, despite my having stated that it does here (above and on stackoverflow)
I'll spend today verifying that.

[dburriss]

@dfdumaresq is targeting netstandard 2 ok or is 1 still required? Recommendation from MS these days seems to be to push for 2. It would allow me to move to latest SO Redis client
https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes

[dfdumaresq]

@dburriss - the RuntimeFrameworkVersion for our production application is currently netcoreapp1.1. and I can't get RedisList to write to a key. So it seems like Netcore 1.1.5 is not supported? Have you ever had it working in Netcore 1.x?

Sorry for the confusing reply.

I was trying to describe our project and I'm not very familiar with the terminology: Here is our target and runtime framework

<TargetFramework>netcoreapp1.1</TargetFramework>
<RuntimeFrameworkVersion>1.1.5</RuntimeFrameworkVersion>

Here's the output from >dotnet --info
.NET Command Line Tools (2.1.101)

Product Information:
 Version:            2.1.101
 Commit SHA-1 hash:  6c22303bf0

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.1.101/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.6
  Build    : 74b1c703813c8910df5b96f304b0f2b78cdf194d

I just need to know if RedisList will work with netcoreapp.1.1. From all my tests, it seems like it will not.

[dfdumaresq]

Hi @dburriss - I followed your suggestion and setup an action that sets up a connection like the one in RedisLoggerConfigurationExt with my setting but without the NoConnectionMultiplexer and instead just throws.

Here's the exception:

Exception has occurred: CLR/System.AggregateException
An exception of type 'System.AggregateException' occurred in dotnet1.x.dll but was not handled in user code: 'One or more errors occurred.'
Inner exceptions found, see $exception in variables window for more details.
Innermost exception System.PlatformNotSupportedException : This platform does not support connecting sockets to DNS endpoints via the instance Connect and ConnectAsync methods, due to the potential for a host name to map to multiple IP addresses and sockets becoming invalid for use after a failed connect attempt. Use the static ConnectAsync method, or provide to the instance methods the specific IPAddress desired.
at System.Net.Sockets.Socket.ThrowIfNotSupportsMultipleConnectAttempts()
at System.Net.Sockets.Socket.BeginConnect(String host, Int32 port, AsyncCallback requestCallback, Object state)
at System.Net.Sockets.SocketTaskExtensions.<>c.b__5_0(String targetHost, Int32 targetPort, AsyncCallback callback, Object state)
at System.Threading.Tasks.TaskFactory1.FromAsyncImpl[TArg1,TArg2](Func5 beginMethod, Func2 endFunction, Action1 endAction, TArg1 arg1, TArg2 arg2, Object state, TaskCreationOptions creationOptions)
at System.Threading.Tasks.TaskFactory.FromAsync[TArg1,TArg2](Func5 beginMethod, Action1 endMethod, TArg1 arg1, TArg2 arg2, Object state)
at System.Net.Sockets.SocketTaskExtensions.ConnectAsync(Socket socket, String host, Int32 port)
at StackExchange.Redis.SocketManager.BeginConnect(EndPoint endpoint, ISocketCallback callback, ConnectionMultiplexer multiplexer, TextWriter log)
at StackExchange.Redis.PhysicalConnection.BeginConnect(TextWriter log)
at StackExchange.Redis.PhysicalBridge.GetConnection(TextWriter log)
at StackExchange.Redis.ServerEndPoint..ctor(ConnectionMultiplexer multiplexer, EndPoint endpoint, TextWriter log)
at StackExchange.Redis.ConnectionMultiplexer.d__119.MoveNext()

The inner exception in the variables window (I'm using VSCode) mentioned above is:

Count = error CS0103: The name 'InnerExceptionCount' does not exist in the current context

[dburriss]

Seems to be mentioned here: StackExchange/StackExchange.Redis#463

I see a workaround mentioned but basically they say fixed with 2.0 bits.

We didn't use 1.1 only 1.0. 1.1 had the reputation of not really being production ready.

[dfdumaresq]

Thanks for that, Devon! I was able to get it working by using a static IP address.

I agree with your suggestion that you add a Debug Log level to the catch. This was a huge headache to debug.