[FEATURE REQUEST] Optional `WAIT` flag for Enqueue

[danthegoodman1]

I think it would be useful to have the option to use or not use WAIT {some number} with Enqueue such that we can have assurance that we durably wrote to Redis (when not using AOF).

Since Redis can lose writes before syncing to a replica, this is still a conern present without AOF.

Maybe an asynq.Wait(int) would be a parameter that would be passed to the client.Enqueue() function.

[hibiken]

@danthegoodman1 Great feature request.

I believe synchronous replication is needed in some use cases and may be a common need. Let me do a little bit more research around this to come up with a suggestion.

Any suggestion on the API is welcome!

[vishjain]

@hibiken Can I submit a PR for this? Thanks!

[danthegoodman1]

bumping, this would be really helpful as temporal overhead is inappropriate for some use cases

[kamikazechaser]

Possibly needs a refactor for https://github.com/hibiken/asynq/blob/master/internal/rdb/rdb.go#L152..

numreplicas and timeout metadata need to be added to base.TaskMessage.

[danthegoodman1]

For those wondering, in the meantime you can just either add AOF (for single host deployments) or you can use a service like upstash redis/aws memorydb that natively has both persistence and HA.

Edit: AOF might work if only a single host in a cluster gets it too, but I have never tested or seen talk of that failover pattern (but I assume based on async replication it would sync it across the cluster)