chore: Capitalize todos and fixmes

coordinator/src/node.rs

@@ -494,7 +494,7 @@ impl Node {
                 .map(Message::SubChannel),
         };
 
-        // todo(holzeis): It would be nice if dlc messages are also propagated via events, so the
+        // TODO(holzeis): It would be nice if dlc messages are also propagated via events, so the
         // receiver can decide what events to process and we can skip this component specific logic
         // here.
         if let Message::Channel(ChannelMessage::RenewFinalize(r)) = &msg {

coordinator/src/node/expired_positions.rs

@@ -77,7 +77,7 @@ pub async fn close(node: Node, trading_sender: mpsc::Sender<NewOrderMessage>) ->
         let new_order = NewOrder {
             id: uuid::Uuid::new_v4(),
             contract_symbol: position.contract_symbol,
-            // todo(holzeis): we should not have to set the price for a market order. we propably
+            // TODO(holzeis): we should not have to set the price for a market order. we propably
             // need separate models for a limit and a market order.
             price: Decimal::ZERO,
             quantity: Decimal::try_from(position.quantity).expect("to fit into decimal"),

coordinator/src/orderbook/trading.rs

@@ -121,7 +121,7 @@ pub fn start(
 }
 
 /// Processes a new limit and market order
-/// todo(holzeis): The limit and market order models should be separated so we can process the
+/// TODO(holzeis): The limit and market order models should be separated so we can process the
 /// models independently.
 ///
 ///
@@ -144,7 +144,7 @@ async fn process_new_order(
 
     // before processing any match we set all expired limit orders to failed, to ensure the do
     // not get matched.
-    // todo(holzeis): orders should probably do not have an expiry, but should either be
+    // TODO(holzeis): orders should probably do not have an expiry, but should either be
     // replaced or deleted if not wanted anymore.
     orders::set_expired_limit_orders_to_failed(conn)?;
 
@@ -176,7 +176,7 @@ async fn process_new_order(
         let matched_orders = match match_order(&order, opposite_direction_orders) {
             Ok(Some(matched_orders)) => matched_orders,
             Ok(None) => {
-                // todo(holzeis): Currently we still respond to the user immediately if there
+                // TODO(holzeis): Currently we still respond to the user immediately if there
                 // has been a match or not, that's the reason why we also
                 // have to set the order to failed here. But actually we
                 // could keep the order until either expired or a
@@ -220,7 +220,7 @@ async fn process_new_order(
                 }
                 Err(e) => {
                     tracing::warn!(%trader_id, order_id, "{e:#}");
-                    // todo(holzeis): send push notification to user
+                    // TODO(holzeis): send push notification to user
 
                     if order.order_type == OrderType::Limit {
                         // FIXME: The maker is currently not connected to the web socket so we

mobile/native/src/ln_dlc/node.rs

@@ -200,7 +200,7 @@ impl Node {
             }
         };
 
-        // todo(holzeis): It would be nice if dlc messages are also propagated via events, so the
+        // TODO(holzeis): It would be nice if dlc messages are also propagated via events, so the
         // receiver can decide what events to process and we can skip this component specific logic
         // here.
         if let Message::Channel(channel_message) = &msg {
@@ -260,7 +260,7 @@ impl Node {
             // received by the UI at the moment indicating that the dialog can be closed.
             // If the dialog is not open, this event would be simply ignored by the UI.
             //
-            // fixme(holzeis): We should not require that event and align the UI handling with
+            // FIXME(holzeis): We should not require that event and align the UI handling with
             // waiting for an order execution in the happy case with waiting for an
             // order execution after an in between restart. For now it was the easiest
             // to go parallel to that implementation so that we don't have to touch it.
@@ -307,7 +307,7 @@ impl Node {
             // received by the UI at the moment indicating that the dialog can be closed.
             // If the dialog is not open, this event would be simply ignored by the UI.
             //
-            // fixme(holzeis): We should not require that event and align the UI handling with
+            // FIXME(holzeis): We should not require that event and align the UI handling with
             // waiting for an order execution in the happy case with waiting for an
             // order execution after an in between restart. For now it was the easiest
             // to go parallel to that implementation so that we don't have to touch it.

mobile/native/src/ln_dlc/sync_position_to_dlc.rs

@@ -88,7 +88,7 @@ impl Node {
     /// Also triggers the `periodic_check` to process any actions that might have been created after
     /// the channel reestablishment.
     ///
-    /// fixme(holzeis): We currently use different events for show the recovery of a dlc and the
+    /// FIXME(holzeis): We currently use different events for show the recovery of a dlc and the
     /// waiting for an order execution in the happy case (without an restart in between). Those
     /// events and dialogs should be aligned.
     async fn recover_dlc(&self) -> Result<()> {
@@ -97,7 +97,7 @@ impl Node {
             BackgroundTask::RecoverDlc(TaskStatus::Pending),
         ));
 
-        // fixme(holzeis): We are manually calling the periodic check here to speed up the
+        // HACK(holzeis): We are manually calling the periodic check here to speed up the
         // processing of pending actions.
         // Note, this might not speed up the process, as the coordinator might have to resend a
         // message to continue the protocol. This should be fixed in `rust-dlc` and any