Since the mysql_async_wasi repo does not have an issue track, I'm reporting to this repo instead.
When testing greptimedb example against GreptimeCloud instance, we are not able to complete SSL handshake. But using the original mysql_async library for default linux target, with default-rustls feature enabled, it works smoothly. So I believe there is potential issue with our mysql_async fork or tls libraries.
Steps to reproduce
Create a GreptimeDB instance on GreptimeCloud, copy all those connection information: host, dbname, username, password
Compile greptimedb example in this repo, and execute with wasmedge --env "DATABASE_URL=mysql://<username>:<password>@<host>:4002/<dbname>" --env "DATABASE_SSL=1" target/wasm32-wasi/debug/greptimedb.wasm
Blocked with no output
What I can see from wireshark (no outbound traffic captured)
There is no traffic after mysql server greeting.
Verify from default target
Change dependency to original mysql_async 0.31 and tokio 1.0, set build target to default
Build the project and run
The example executed successfully and wireshark shows encrypted traffic.
Since the mysql_async_wasi repo does not have an issue track, I'm reporting to this repo instead.
When testing greptimedb example against GreptimeCloud instance, we are not able to complete SSL handshake. But using the original mysql_async library for default linux target, with
default-rustls
feature enabled, it works smoothly. So I believe there is potential issue with our mysql_async fork or tls libraries.Steps to reproduce
wasmedge --env "DATABASE_URL=mysql://<username>:<password>@<host>:4002/<dbname>" --env "DATABASE_SSL=1" target/wasm32-wasi/debug/greptimedb.wasm
What I can see from wireshark (no outbound traffic captured) There is no traffic after mysql server greeting.
Verify from default target
mysql_async
0.31 andtokio
1.0, set build target to defaultThe example executed successfully and wireshark shows encrypted traffic.