queuedNewConn panic: cannot create context from nil parent

[schmittjoaopedro]

Hi Redis team,

I have noticed some error logs in our application using the library. I don't have a reproducible scenario for it, but I decided to file an issue anyway so the team can investigate if it's a real issue and maybe post a fix for it:

2025-11-25 18:33:42.097
redis: 2025/11/25 18:33:40 pool.go:590: queuedNewConn panic: cannot create context from nil parent
2025-11-25 18:33:43.735
redis: 2025/11/25 18:33:42 pool.go:590: queuedNewConn panic: cannot create context from nil parent
2025-11-25 18:33:59.134
redis: 2025/11/25 18:33:45 pool.go:590: queuedNewConn panic: cannot create context from nil parent
2025-11-25 18:33:59.935
redis: 2025/11/25 18:33:43 pool.go:590: queuedNewConn panic: cannot create context from nil parent
2025-11-25 18:34:01.730
redis: 2025/11/25 18:32:59 pool.go:590: queuedNewConn 
2025-11-25 18:35:08.562
redis: 2025/11/25 18:35:08 pool.go:422: redis: connection pool: failed to dial after 1 attempts: dial tcp: lookup <master node domain>: i/o timeout
2025-11-25 18:35:08.562
redis: 2025/11/25 18:35:08 pool.go:422: redis: connection pool: failed to dial after 1 attempts: dial tcp: lookup <master node domain>: i/o timeout
2025-11-25 18:35:08.562
redis: 2025/11/25 18:35:08 pool.go:422: redis: connection pool: failed to dial after 1 attempts: dial tcp: lookup <master node domain>: i/o timeout
2025-11-25 18:35:08.562
redis: 2025/11/25 18:35:08 pool.go:422: redis: connection pool: failed to dial after 1 attempts: dial tcp: lookup <master node domain>: i/o timeout
2025-11-25 18:35:08.562
redis: 2025/11/25 18:35:08 pool.go:422: redis: connection pool: failed to dial after 1 attempts: dial tcp: lookup <master node domain>: i/o timeout
2025-11-25 18:35:55.779
redis: 2025/11/25 18:33:59 pool.go:590: queuedNewConn 
2025-11-25 18:36:31.117
redis: 2025/11/25 18:33:59 pool.go:590: queuedNewConn panic: cannot create context from nil parent
2025-11-25 18:36:31.117
redis: 2025/11/25 18:33:59 pool.go:590: queuedNewConn panic: cannot create context from nil parent
2025-11-25 18:36:31.148
redis: 2025/11/25 18:33:37 pool.go:590: queuedNewConn panic: cannot create context from nil parent
2025-11-25 18:36:31.206
redis: 2025/11/25 18:33:37 pool.go:590: queuedNewConn panic: cannot create context from nil parent

[cyningsun]

hi @schmittjoaopedro thank you for reporting this issue and providing the logs.

I reviewed the panic stack trace and the root cause should be: a race condition in the connection creation logic where a nil context can be passed to context.WithTimeout after a request times out. Here is the details:

T1: The main goroutine calls queuedNewConn(ctx), creating a background goroutine.
T2: The background goroutine starts but has not yet executed getCtxForDial().
T3: The main goroutine times out waiting (ctx.Done()), sets an error, and prepares to return.
T4: The main goroutine executes defer, calls w.cancel(), and sets w.ctx to nil.
T5: The background goroutine executes line where getCtxForDial() returns nil.
T6: The background goroutine calls p.newConn(nil, true).
T7: Inside newConn, a call to context.WithTimeout(nil, ...) triggers a panic.

[ndyakov]

Hello @schmittjoaopedro, can you state the version that panics. Which version is that, I can see it in the latest patch as well if I am not mistaken.

@cyningsun Let me know what you think and if you would like to handle this or should I?

This panic is handled which is good and makes this not a critical issue. Maybe we can handle this specific case explicitly and return an error or even fallback to background context in newConn?

[cyningsun]

@ndyakov, thanks for looking into this. You're correct — based on the code review, I think this race condition also exists in the latest version.

I agree that since the panic is already recovered upstream, it's not a critical production issue. For the fix,how about we avoid the race entirely by moving all context handling inside the background goroutine? Since it doesn’t actually need the original request context for anything (like tracing or deadlines) now, we could just create a fresh background context with the pool’s DialTimeout inside the background goroutine. This would cleanly decouple it from the main goroutine’s lifecycle and eliminate the nil pointer risk.

On timing: If you have cycles to lead the fix, that would likely be fastest — my week is quite packed. I'm happy to review or pick it up later this week if needed.

[ndyakov]

@cyningsun I can try to fit it around end of week or start of next one.
Your suggestion sounds good, will investigate where exactly it will make sense to create the new context and open a PR to continue the discussion.

[schmittjoaopedro]

Hi @ndyakov we observed that in version 6.17.0