Summary

When an admin action (AdminSettle, AdminCancel) receives an order_id that is not present in the database, the daemon returns MostroError::MostroInternalErr(ServiceError::InvalidOrderId), which is mapped to warning_msg(...) in app.rs::manage_errors. warning_msg
only logs locally via tracing::warn! and never enqueues a DM back to the sender. The client therefore never learns the action failed, and
ends up waiting for a response that never comes (timing out).

This is the root cause of MostroP2P/mostro-cli#170 on the daemon side (the CLI side is being fixed independently).

Current behavior

1. Admin sends Action::AdminSettle with a non-existent order_id.
2. admin_settle_action calls get_order(...) which returns Err(MostroInternalErr(ServiceError::InvalidOrderId)) (see mostro/src/util.rs:1169-1182).
3. manage_errors (mostro/src/app.rs:88-107) matches the MostroInternalErr arm, which calls warning_msg(action, e) and returns without sending any DM.
4. Backend logs show: Error in AdminSettle with context Order id not present in database - inner message No message
5. The admin client receives nothing.

Expected behavior

InvalidOrderId is a user-correctable input error, not an internal fault — the client should be told. The daemon should send a
CantDo(NotFound) (or a more specific reason if added) DM back to the sender so the admin sees that the order id was invalid.

A broader sweep is probably worthwhile: any ServiceError variant that is actually caused by user input (invalid id, malformed input, etc.)
should probably be promoted to a CantDo rather than left as an internal error.

Suggested fix

Either:

• In get_order, return MostroCantDo(CantDoReason::NotFound) instead of MostroInternalErr(ServiceError::InvalidOrderId); or
• In manage_errors, treat the specific ServiceError::InvalidOrderId variant by enqueueing a CantDo(NotFound)` DM in addition to logging.

The first option is more surgical and matches the semantics of CantDoReason (machine-readable, intended to be surfaced to users).

Affected actions

Confirmed: AdminSettle, AdminCancel. Likely the same pattern affects any handler that calls get_order and returns its error unmodified.

Additional context

Related CLI issue: MostroP2P/mostro-cli#170