captchanjack / jedis.jl Goto Github PK

When the Jedis system executes commands into Redis, the RESP function uses the string length to determine the byte buffer size. In the case of Julia strings, a unicode character is 1 character size, but has a larger byte size.

For example, on a write command with a non-ascii character such as the en-dash (– vs -) has a 3 byte size but one character size. The en-dash will write into Redis as \xe2\x80\x93 and the last two characters of the total string will be lost.

Jedis.write("test", "A string with an en–dash")

will write

get test
A string with an en\xe2\x80\x93da

I just discovered this project, and almost missed it, since the basically unmaintained Redis.jl is front and center at Google search results, probably because it is part of JuliaDatabases.

I want to ask you if you may be interested, to move this project to this organization as well?

There is a dangerous use of GC in the client setup, which is used in the reconnection logic. See:

• GC in prepare!: https://github.com/captchanjack/Jedis.jl/blob/main/src/client.jl#L113
• Use of prepare! in reconnect!: https://github.com/captchanjack/Jedis.jl/blob/main/src/client.jl#L241

Should this be a gc, or a safepoint call to allow the gc to scan correctly?

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

The function wait_for_decrypted_data has been removed in MbedTLS 1.1.6. As a result, when I try to create a client, I get the following error: LoadError: UndefVarError: wait_for_decrypted_data not defined.