diesel_async fails to connect to MariaDB, while pure diesel works fine

[crai0n]

Setup

I'm working on macOS 14.6.1, running a MariaDB instance in a Docker Container.

Versions

• Rust: rustc 1.80.1 (stable)
• Diesel: "2.2.3"
• Diesel_async: "0.5.0"
• Database: 11.5.2-MariaDB-ubu2404
• Operating System macOS (Docker)

Feature Flags

• diesel: default-features = false (for the sync version ["mysql"])
• diesel_async: ["mysql"]

Problem Description

I'm building a small POC of a webserver using actix-web with database access. I'm running a MariaDB instance in a Docker Container. Initially, I set up the connection using pure diesel which was working fine. During installation of diesel, cargo apparently compiled in the mysql libraries provided by my local MariaDB installation.

When making the switch to diesel_async, I basically made a one-to-one replacement of all function calls.

The web-server still compiles, but panics immediately. The database connection is now failing. Using pure diesel, the connection was established fine, while using diesel_async resulted in an error:

Backend(ConnectionError(BadConnection("Unknown authentication plugin `client_ed25519')))

Digging further, the problem seems to be that I was trying to use MariaDB's ed25519 authentication module.

After switching the user authentication method to mysql_native_password on the server, the error disappears. It seems to me that for some reason diesel_async uses a different client or a different way of integrating MySQL plugins/modules than pure diesel. Looking through the feature flags, I found no obvious way to configure this as a user so I am hoping for pointers.

What are you trying to accomplish?

Connect to a MariaDB instance asynchronously using ed25519 authentication module.

What is the expected output?

Successful connection established, web server starts up

What is the actual output?

Connection fails with Backend(ConnectionError(BadConnection("Unknown authentication plugin 'client_ed25519'))), webserver panics

Are you seeing any additional errors?

Steps to reproduce

main.rs (with diesel_async, failing):

use actix_web::{get, App, HttpResponse, HttpServer, Responder};
use diesel_async::{AsyncConnection, AsyncMysqlConnection};

mod models;
mod schema;

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let database_url = "mysql://root:[email protected]/diesel_demo".to_string();
    AsyncMysqlConnection::establish(&database_url)
        .await
        .unwrap_or_else(|e| panic!("Error connecting to {}: {:?}", database_url, e));

    HttpServer::new(move || App::new().service(healthcheck))
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
}

#[get("/hc")]
async fn healthcheck() -> impl Responder {
    HttpResponse::Ok().finish()
}

main.rs (with diesel, working):

use actix_web::{get, App, HttpResponse, HttpServer, Responder};
use diesel::{Connection, MysqlConnection};

mod models;
mod schema;

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let database_url = "mysql://root:[email protected]/diesel_demo".to_string();
    MysqlConnection::establish(&database_url)
        .unwrap_or_else(|e| panic!("Error connecting to {}: {:?}", database_url, e));

    HttpServer::new(move || App::new().service(healthcheck))
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
}

#[get("/hc")]
async fn healthcheck() -> impl Responder {
    HttpResponse::Ok().finish()
}

Checklist

• I have already looked over the issue tracker for similar possible closed issues.
• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate

[weiznich]

Thanks for reporting this issue.

diesel_async don't implement the actual connection mechanisms for mysql. It relies on the mysql_async. That means we cannot change the implementation here, you likely should consider filling a bug in that crate. I would appreciate if you can add the link to the upstream issue here afterwards.

Closed as this is an upstream bug.

[crai0n]

Dear @weiznich,

thanks for pointing me in the direction of mysql_async. I have traced the source of the issue further to mysql_common, who don't currently support this auth_protocol. There already is an issue on this topic here.

Apparently, the authentification method will be superseded by a new scheme. Until then, I will keep using mysql_native_password.