portacode 1.3.30__tar.gz → 1.3.31__tar.gz

{portacode-1.3.30 → portacode-1.3.31}/.claude/settings.local.json

@@ -15,8 +15,9 @@
       "Bash(mkdir:*)",
       "Bash(./connect.sh)",
       "Bash(git -C /home/menas/testing_folder status --porcelain)",
-      "Bash(docker-compose restart:*)"
+      "Bash(docker-compose restart:*)",
+      "Bash(./debug/list_user_devices_and_projects.sh:*)"
     ],
     "deny": []
   }
-}
+}

{portacode-1.3.30 → portacode-1.3.31}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: portacode
-Version: 1.3.30
+Version: 1.3.31
 Summary: Portacode CLI client and SDK
 Home-page: https://github.com/portacode/portacode
 Author: Meena Erian

{portacode-1.3.30 → portacode-1.3.31}/portacode/_version.py

@@ -28,7 +28,7 @@ version_tuple: VERSION_TUPLE
 commit_id: COMMIT_ID
 __commit_id__: COMMIT_ID
 
-__version__ = version = '1.3.30'
-__version_tuple__ = version_tuple = (1, 3, 30)
+__version__ = version = '1.3.31'
+__version_tuple__ = version_tuple = (1, 3, 31)
 
 __commit_id__ = commit_id = None

{portacode-1.3.30 → portacode-1.3.31}/portacode/connection/handlers/project_state/file_system_watcher.py

@@ -28,12 +28,13 @@ except ImportError:
 
 class FileSystemWatcher:
     """Watches file system changes for project folders."""
-    
+
     def __init__(self, project_manager):
         self.project_manager = project_manager  # Reference to ProjectStateManager
         self.observer: Optional[Observer] = None
         self.event_handler: Optional[FileSystemEventHandler] = None
         self.watched_paths: Set[str] = set()
+        self.watch_handles: dict = {}  # Map path -> watch handle for proper cleanup
         # Store reference to the event loop for thread-safe async task creation
         try:
             self.event_loop = asyncio.get_running_loop()
@@ -140,14 +141,15 @@ class FileSystemWatcher:
         if not WATCHDOG_AVAILABLE or not self.observer:
             logger.warning("Watchdog not available, cannot start watching: %s", path)
             return
-        
+
         if path not in self.watched_paths:
             try:
                 # Use recursive=False to watch only direct contents of each folder
-                self.observer.schedule(self.event_handler, path, recursive=False)
+                watch_handle = self.observer.schedule(self.event_handler, path, recursive=False)
                 self.watched_paths.add(path)
+                self.watch_handles[path] = watch_handle  # Store handle for cleanup
                 logger.info("Started watching path (non-recursive): %s", path)
-                
+
                 if not self.observer.is_alive():
                     self.observer.start()
                     logger.info("Started file system observer")
@@ -161,14 +163,15 @@ class FileSystemWatcher:
         if not WATCHDOG_AVAILABLE or not self.observer:
             logger.warning("Watchdog not available, cannot start watching git directory: %s", git_path)
             return
-        
+
         if git_path not in self.watched_paths:
             try:
                 # Watch .git directory recursively to catch changes in refs/, logs/, etc.
-                self.observer.schedule(self.event_handler, git_path, recursive=True)
+                watch_handle = self.observer.schedule(self.event_handler, git_path, recursive=True)
                 self.watched_paths.add(git_path)
+                self.watch_handles[git_path] = watch_handle  # Store handle for cleanup
                 logger.info("Started watching git directory (recursive): %s", git_path)
-                
+
                 if not self.observer.is_alive():
                     self.observer.start()
                     logger.info("Started file system observer")
@@ -181,9 +184,19 @@ class FileSystemWatcher:
         """Stop watching a specific path."""
         if not WATCHDOG_AVAILABLE or not self.observer:
             return
-        
+
         if path in self.watched_paths:
-            # Note: watchdog doesn't have direct path removal, would need to recreate observer
+            # Actually unschedule the watch using stored handle
+            watch_handle = self.watch_handles.get(path)
+            if watch_handle:
+                try:
+                    self.observer.unschedule(watch_handle)
+                    logger.info("Successfully unscheduled watch for: %s", path)
+                except Exception as e:
+                    logger.error("Error unscheduling watch for %s: %s", path, e)
+                finally:
+                    self.watch_handles.pop(path, None)
+
             self.watched_paths.discard(path)
             logger.debug("Stopped watching path: %s", path)
     
@@ -192,4 +205,5 @@ class FileSystemWatcher:
         if self.observer and self.observer.is_alive():
             self.observer.stop()
             self.observer.join()
-            self.watched_paths.clear()
+            self.watched_paths.clear()
+            self.watch_handles.clear()

{portacode-1.3.30 → portacode-1.3.31}/portacode.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: portacode
-Version: 1.3.30
+Version: 1.3.31
 Summary: Portacode CLI client and SDK
 Home-page: https://github.com/portacode/portacode
 Author: Meena Erian

{portacode-1.3.30 → portacode-1.3.31}/portacode.egg-info/SOURCES.txt

@@ -86,6 +86,10 @@ testing_framework/core/playwright_manager.py
 testing_framework/core/runner.py
 testing_framework/core/shared_cli_manager.py
 testing_framework/core/test_discovery.py
+todo/agent_context_management.md
+todo/issues/device_performance_degradation.md
+todo/issues/git_data_not_captured_in_proxmox.md
 todo/issues/indefinite_resource_loading.md
 todo/issues/premature_terminal_exit.md
+todo/issues/terminals_exit_upon_starting.md
 tools/test_python_ntp_clock.py

portacode-1.3.31/todo/agent_context_management.md

@@ -0,0 +1,12 @@
+# Agent Context Management
+
+This document describes how the unibot portacode agent is expected to access contextual information to complete show awerness of user data. It is in the form of phases to be implemented one by one.
+
+
+# Phase one: Project selection
+
+- Each account object should carry some state data, which needs to include the fields "Selected Project": project UUID (can be null and default is null)
+- A user can only select a project if they are authorized to access that project. And by default, no pojects are selected.
+- project selection data should be accessible through the Account model
+- the agent/bot needs to be equipped with a tool to select/unselect projects
+- The system message of the agent is affected by which project is currently selected. If non, in contains data similar to that in the dashboard page. If a project is selected, it shows data similar to that of the project page. 

portacode-1.3.31/todo/issues/device_performance_degradation.md

@@ -0,0 +1,129 @@
+# Device Performance Degradation over time.
+
+## **CONFIRMED ROOT CAUSE (2025-10-13)**
+
+**Trigger: Opening/refreshing project workspace pages for git repositories**
+
+Experimental findings:
+- ✅ Terminal sessions have NO impact on performance (can run for days with heavy I/O)
+- ✅ Project workspace pages WITHOUT .git folder: always fast, no degradation
+- ❌ Project workspace pages WITH .git folder: **catastrophic degradation**
+  - 1st load: takes several seconds
+  - 2nd load: noticeably slower
+  - 5th load: barely responsive, device goes offline momentarily
+
+**Diagnostic evidence from running service (PID 1891992, 16+ hours uptime):**
+- 200 pipes (normally <20)
+- 65 threads (normally 5-10)
+- 91% sustained CPU usage
+- Performance: 55ms → 12,418ms (224x slowdown)
+
+**Primary culprit: Watchdog file system watcher + Git operations**
+- file_system_watcher.py:186-188 - `stop_watching()` doesn't unschedule watches
+- file_system_watcher.py:168 - .git directories watched **recursively**
+- manager.py:904 - Every project state refresh adds .git watch
+- Result: Orphaned watches accumulate, every file change triggers 100+ unnecessary handlers
+
+---
+
+## Original Issue Description
+
+When we run "portacode connect" or "portacode service install" and the device gets connected, initially, the totall time elapsed from the moment a client session sends a command to the device till the device response event arrivs back to the client session is typically less than 100ms with an average of 55ms. However, when we start actively using the device, the device starts to slow down gradually until within just a couple of hours or so, it becomes so slow it takes more than 12 seconds! The trace looks something like this:
+
+{
+    "client_send": 1760282723260.5,
+    "ping": 12418,
+    "server_receive": 1760282723264,
+    "server_send": 1760282723278,
+    "device_receive": 1760282727601,
+    "handler_receive": 1760282728420,
+    "handler_dispatch": 1760282728420,
+    "handler_complete": 1760282735611,
+    "device_send": 1760282735611,
+    "server_receive_response": 1760282735611,
+    "server_send_response": 1760282735611,
+    "client_receive": 1760282735678.5
+}
+
+ Client → Server: 3.50ms
+ Server Processing: 14.00ms
+ Server → Device: 4323.00ms
+ Device Processing: 819.00ms
+ Handler Queue: 0.00ms
+ Handler Execution: 7191.00ms
+ Device Response: 0.00ms
+ Device → Server: 0.00ms
+ Server → Client: 67.50ms
+TOTAL: 12418.00ms
+
+While the trace might missleadingly make it look like the connection Server → Device is contributing to the issue, but the truth is that the timestamp taken in the device side not immidiately as soon as the message is actually received. It's also clear from the "Device Processing" and the "Handler Execution" that the device is actually very slow. We also tried closing all terminal sessions in the device assuming some might be overwhelming it with the size of their buffer or so but that didn't change anything and it stayed very slow until we restart the portacode service.
+
+
+  Hypothesis 1: Asyncio Task Accumulation (Memory Leak)
+
+  Location: Multiple locations throughout the codebase
+
+  Evidence:
+  - asyncio.create_task() is called extensively but tasks are rarely tracked or cleaned up:
+    - Terminal session debounce tasks: /home/menas/portacode/portacode/connection/handlers/session.py:260
+    - File watcher event handling: /home/menas/portacode/portacode/connection/handlers/project_state/file_system_watcher.py:125-128
+    - Project state refresh tasks: /home/menas/portacode/portacode/connection/terminal.py:502-503
+    - Git change callbacks: /home/menas/portacode/portacode/connection/handlers/project_state/manager.py:840
+
+  Why it causes degradation:
+  - Each uncancelled/uncompleted task consumes memory and CPU
+  - Over hours of usage, thousands of orphaned tasks accumulate in the event loop
+  - The event loop has to check all pending tasks on each iteration, causing exponential slowdown
+  - The 7191ms "Handler Execution" time suggests the event loop is overwhelmed
+
+  Key smoking gun: Line 260 in session.py creates debounce tasks for terminal data that may never complete if terminals are long-running. Similarly, line 840 in
+  manager.py creates tasks without storing references to cancel them later.
+
+  ---
+  Hypothesis 2: Git Operations Blocking the Event Loop
+
+  Location: /home/menas/portacode/portacode/connection/handlers/project_state/git_manager.py and
+  /home/menas/portacode/portacode/connection/handlers/project_state/manager.py
+
+  Evidence:
+  - Git periodic monitoring runs every 1 second checking full repository status: git_manager.py:1839
+  - File system watcher triggers git operations on every file change: manager.py:842-878
+  - Many git operations are NOT using run_in_executor despite being synchronous I/O
+  - get_file_status_batch() performs multiple git commands per file: git_manager.py:295-406
+
+  Why it causes degradation:
+  - Git operations on large repos can take 100-500ms each
+  - With active file editing, git operations are triggered continuously
+  - The synchronous git calls block the event loop, preventing handlers from processing
+  - The 819ms "Device Processing" + 7191ms "Handler Execution" = 8010ms spent in device-side operations
+
+  Key smoking gun: Line 1839 shows monitoring runs every 1 second, and lines 372-407 show batch git operations that aren't async-wrapped, causing cumulative
+  blocking over time.
+
+  ---
+  Hypothesis 3: Watchdog File System Watcher Resource Leak
+
+  Location: /home/menas/portacode/portacode/connection/handlers/project_state/file_system_watcher.py and
+  /home/menas/portacode/portacode/connection/handlers/project_state/manager.py
+
+  Evidence:
+  - Watchdog observers are created but never stopped: file_system_watcher.py:136
+  - .git directories are watched recursively: file_system_watcher.py:168
+  - New paths are added to watched_paths but cleanup only discards from set without stopping observers: file_system_watcher.py:180-188
+  - Multiple project sessions can create multiple watchers for overlapping paths
+
+  Why it causes degradation:
+  - Each watchdog observer creates background threads that consume resources
+  - Recursive watching of .git/objects/ can trigger thousands of events during git operations
+  - File system events queue up faster than they can be processed
+  - The cross-thread communication (watchdog thread → asyncio event loop) adds overhead
+
+  Key smoking gun: Line 168 watches git directories recursively, and line 186 shows stop_watching() only removes from the set but doesn't actually stop the observer
+   schedules. The Observer instance lives for the lifetime of the watcher, accumulating schedules.
+
+  ---
+  Recommended Investigation Order:
+
+  1. Check for task accumulation first (use asyncio.all_tasks() to count pending tasks)
+  2. Profile git operation frequency and duration
+  3. Check watchdog observer thread count and file descriptor usage