feat: wrap not found error

[dewabisma]

We don't want to overload metrics with useless error. So, not found data in db or handler will be wrapped in status 200 but contain error message still.

[n13]

Reviewed PR #60.

• High – global DbError::RecordNotFound remap changes auth/login semantics unintentionally
  • In src/errors.rs, DbError::RecordNotFound now maps to StatusCode::OK, which applies to all call sites, not just the tweet/raid paths.
  • handle_admin_login in src/handlers/auth.rs raises DbError::RecordNotFound when username is missing, so this PR makes “admin not found” return HTTP 200 with an error body instead of a non-2xx auth failure signal.
  • This can break clients/middlewares that rely on status code for auth control flow and can mask auth failures in upstream monitoring.
  • Code path involved:

fn map_db_error(err: DbError) -> (StatusCode, String) {
    match err {
        DbError::UniqueViolation(err) => (StatusCode::CONFLICT, err),
        DbError::RecordNotFound(err) | DbError::AddressNotFound(err) => (StatusCode::OK, err),

let admin = state
    .db
    .admin
    .find_by_username(&body.username)
    .await?
    .ok_or(AppError::Database(DbError::RecordNotFound(format!(
        "Admin with username {} is not exist",
        &body.username,

• Medium – missing regression coverage for the global status-code change

  • The PR updates tests for raid/tweet not-found cases, but there is no test asserting expected status/body for auth admin login “user not found” after this global remap.
  • Given the broad blast radius (map_db_error), this leaves other endpoints vulnerable to silent behavior drift.

• Testing gap observed locally

  • I couldn’t fully validate integration behavior end-to-end in this environment because targeted integration test execution timed out on DB pool init (PoolTimedOut), so runtime verification is incomplete here.

If you want, I can draft a minimal follow-up patch that scopes 200 + {"error":...} to only the intended handlers instead of all DbError::RecordNotFound call sites.

[n13]

Review:
The DbError::RecordNotFound -> 200 remap is intentionally broad and still affects all not-found DB paths; that appears aligned with PR intent, but it’s worth a quick API contract sanity check for clients that previously relied on 404 semantics

Can you explain this?

Isn't that a bad thing if this error returns 200 for all access points?

[dewabisma]

This seems not a good approach to the problem. I will close it.