feat: change async-bb8 fork and tokio spawn for concurrent database calls

[jarnura]

Type of Change

• Enhancement
• Refactoring
• Dependency updates

Description

• Currently, In GetTracker, UpdateTracker, and PostUpdateTracker, the concurrent database calls become sequential because of the mutex lock of async-bb8 to get a connection from the connection pool.

  • The I/O(Database call), which ends and releases the lock, makes all concurrent calls sequential.

• Any errors inside the spawned concurrent calls propagated as an internal server error.

Solution:

• Instead, use the has_broken function from the connection manager to check whether a connection is valid and run the function immediately. So that inside all concurrent calls, acquire a lock to pick a connection and then release before doing an I/O call.

  • These changes where made in a fork of async-bb8
  • async-bb8-diesel = { git = "https://github.com/jarnura/async-bb8-diesel", rev = "53b4ab901aab7635c8215fd1c2d542c8db443094" }

• Match on the JoinHandle and propagate the join error as an internal server error and others as it is.

  • created a function called flatten_join_error to propagate the proper error.

• The runtime changed into tokio::main, so that we get more performance with tokio::spawn instead using actix-web::main

• Added Box::pin to large futures

Motivation and Context

To reduce the overall latency of the confirm call.

How did you test it?

A load test setup is required with tracing enabled. A minimalistic postman load test tool itself suffices.

Enable traces_enabled=true, use_xray_generator = true. Run the load test, narrow it down to get_traces in traces, and check the waterfall.

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible
• I added a CHANGELOG entry if applicable