starred/asynq

Fork 0

mirror of https://github.com/hibiken/asynq.git synced 2026-04-26 15:35:55 +03:00

[GH-ISSUE #583] RedisFailoverClientOpt doesn't have SentinelUsername field #1297

New issue

Closed

opened 2026-03-07 22:08:23 +03:00 by kerem · 4 comments

kerem commented

2026-03-07 22:08:23 +03:00

Owner

Originally created by @khasanovbi on GitHub (Dec 6, 2022).
Original GitHub issue: https://github.com/hibiken/asynq/issues/583

Originally assigned to: @hibiken on GitHub.

RedisFailoverClientOpt doesn't have SentinelUsername field

Originally created by @khasanovbi on GitHub (Dec 6, 2022). Original GitHub issue: https://github.com/hibiken/asynq/issues/583 Originally assigned to: @hibiken on GitHub. RedisFailoverClientOpt doesn't have SentinelUsername field

kerem

2026-03-07 22:08:23 +03:00

closed this issue
added the
bug

good first issue
labels

kerem commented

2026-03-07 22:08:24 +03:00

Author

Owner

@vernonr3 commented on GitHub (Jan 6, 2023):

Hello Ken (@hibiken)
Fix this issue in one sense is simply about adding the SentinelUsername to the struct. However in doing this a number of underlying issues are exposed:

should the redis-sentinel URI scheme change from redis-sentinel://[:password@]host1[:port][,host2:[:port]][,hostN:[:port]][?master=masterName] to include username? For example redis-sentinel://[username][:password@]host1[:port][,host2:[:port]][,hostN:[:port]][?master=masterName] ?
if this is case should the other URI schemes also change to include usernames? This would also potentially help issue #591
there aren't mocked tests for unit testing against the redis interface. The current tests rely on a real redis instance being available. Test code appears for the standalone and cluster variants but not AFAIK for the sentinel variant.

What is the policy here? Should we fix it on a "simple" basis - or make the fix more complex by working to improve the rest of the testing code? I'm wondering how big an issue this is for the user community?
Thanks

@vernonr3 commented on GitHub (Jan 6, 2023): Hello Ken (@hibiken) Fix this issue in one sense is simply about adding the SentinelUsername to the struct. However in doing this a number of underlying issues are exposed: - should the redis-sentinel URI scheme change from redis-sentinel://[:password@]host1[:port][,host2:[:port]][,hostN:[:port]][?master=masterName] to include username? For example redis-sentinel://[username][:password@]host1[:port][,host2:[:port]][,hostN:[:port]][?master=masterName] ? - if this is case should the other URI schemes also change to include usernames? This would also potentially help issue #591 - there aren't mocked tests for unit testing against the redis interface. The current tests rely on a real redis instance being available. Test code appears for the standalone and cluster variants but **not** AFAIK for the sentinel variant. What is the policy here? Should we fix it on a "simple" basis - or make the fix more complex by working to improve the rest of the testing code? I'm wondering how big an issue this is for the user community? Thanks

kerem commented

2026-03-07 22:08:24 +03:00

Author

Owner

@shuqingzai commented on GitHub (Nov 15, 2023):

Can this problem be fixed in the near future? @hibiken

We are using sentinel mode but cannot configure SentinelUsername in asynq

@shuqingzai commented on GitHub (Nov 15, 2023): Can this problem be fixed in the near future? @hibiken We are using sentinel mode but cannot configure SentinelUsername in asynq

kerem commented

2026-03-07 22:08:24 +03:00

Author

Owner

@Skwol commented on GitHub (Oct 25, 2024):

Added PR for this issue.

Since asynq uses github.com/redis/go-redis/v9 you can create your own options as a workaround. It will look like that:

// asynq does not support multiple users via their default asynq.FailoverOptions, so we need to create our own
type asynqRedisClientOpt struct {
	clientName             string
	masterName             string
	sentinelUsername       string
	sentinelPassword       string
	sentinelAddrsWithPorts []string
	username               string
	password               string
	db                     int
	tlsConfig              *tls.Config
	dialTimeout            time.Duration
}

func (a asynqRedisClientOpt) MakeRedisClient() interface{} {
	return redis.NewFailoverClient(&redis.FailoverOptions{
		ClientName:       a.clientName,
		MasterName:       a.masterName,
		SentinelUsername: a.sentinelUsername,
		SentinelPassword: a.sentinelPassword,
		SentinelAddrs:    a.sentinelAddrsWithPorts,
		Username:         a.username,
		Password:         a.password,
		DB:               a.db,
		TLSConfig:        a.tlsConfig,
		DialTimeout:      a.dialTimeout,
	})
}

@Skwol commented on GitHub (Oct 25, 2024): Added [PR](https://github.com/hibiken/asynq/pull/924) for this issue. Since asynq uses `github.com/redis/go-redis/v9` you can create your own options as a workaround. It will look like that: ``` // asynq does not support multiple users via their default asynq.FailoverOptions, so we need to create our own type asynqRedisClientOpt struct { clientName string masterName string sentinelUsername string sentinelPassword string sentinelAddrsWithPorts []string username string password string db int tlsConfig *tls.Config dialTimeout time.Duration } func (a asynqRedisClientOpt) MakeRedisClient() interface{} { return redis.NewFailoverClient(&redis.FailoverOptions{ ClientName: a.clientName, MasterName: a.masterName, SentinelUsername: a.sentinelUsername, SentinelPassword: a.sentinelPassword, SentinelAddrs: a.sentinelAddrsWithPorts, Username: a.username, Password: a.password, DB: a.db, TLSConfig: a.tlsConfig, DialTimeout: a.dialTimeout, }) } ```

kerem commented

2026-03-07 22:08:24 +03:00

Author

Owner

@kamikazechaser commented on GitHub (Oct 26, 2024):

you can create your own options as a workaround.

I also recommend this. Gives users a lot more flexibility. It was a lesser known possibility so I added it to the documentation last week.

https://github.com/hibiken/asynq/wiki/Getting-Started#reuse-an-existing-go-redis-connection-pool

As for this issue specifically, I think we can just add the field to the struct and more complex redis connection setups can use a similar approach above.

@kamikazechaser commented on GitHub (Oct 26, 2024): > you can create your own options as a workaround. I also recommend this. Gives users a lot more flexibility. It was a lesser known possibility so I added it to the documentation last week. https://github.com/hibiken/asynq/wiki/Getting-Started#reuse-an-existing-go-redis-connection-pool As for this issue specifically, I think we can just add the field to the struct and more complex redis connection setups can use a similar approach above.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/asynq#1297

No description provided.

Rows
Columns