Merge pull request #194 from quangdang46/fix/reload-loop-same-binary

fix(reload): skip candidate that resolves to current binary (#157, #160)

Author: quangdang46

src/server/util.rs

@@ -123,6 +123,18 @@ pub(crate) fn server_has_newer_binary() -> bool {
     }
 
     candidates.into_iter().any(|candidate| {
+        // If the candidate canonicalizes to the same file as the running binary,
+        // there is by definition no newer binary to reload into. Without this
+        // guard, a stable channel symlink that points back at the running
+        // versioned binary (or a release whose mtime was bumped after process
+        // start, e.g. by a re-install) would drive an infinite reload loop.
+        // See issues #157, #160 and the `hash=unknown` reload symptom.
+        if let Some(current_canon) = current_canonical.as_ref()
+            && current_canon == &candidate
+        {
+            return false;
+        }
+
         let candidate_mtime = std::fs::metadata(&candidate)
             .ok()
             .and_then(|m| m.modified().ok());

src/tui/app/tui_lifecycle_runtime.rs

@@ -155,6 +155,20 @@ impl App {
             return false;
         };
 
+        // Same fix as server_has_newer_binary: if the candidate file
+        // canonicalizes to the same path as the currently running binary,
+        // there is nothing to reload into. This prevents the infinite
+        // reload loop reported in issues #157 and #160 where the stable
+        // channel resolves back to the running versioned binary but with
+        // a freshly-bumped mtime (e.g. after a re-install).
+        if let Ok(candidate_canon) = std::fs::canonicalize(&candidate)
+            && let Ok(current_exe) = std::env::current_exe()
+            && let Ok(current_canon) = std::fs::canonicalize(&current_exe)
+            && candidate_canon == current_canon
+        {
+            return false;
+        }
+
         std::fs::metadata(&candidate)
             .ok()
             .and_then(|m| m.modified().ok())