Communication wtih session stops working after a while #140

Activity

1. hcsolakoglu commented on Sep 24, 2026

   

   hcsolakoglu

   on Sep 24, 2026

   More actions

   I traced an additional data-integrity consequence of the file-operation failure described here.

   On current main (e25c2655), colab edit treats any download exception as if the remote file does not exist:

   try:
       contents.download(remote_path, local_path)
   except Exception:
       # If download fails, assume file doesn't exist and start empty
       pass

   If the remote file actually exists but the download fails because of a transport, authentication, runtime-proxy, or server error, the editor is still opened on the temporary file. If the user then saves changes and the later upload succeeds, those contents are uploaded to the original remote path. That creates a path from a failed read to overwriting an existing remote file.

   I reproduced this deterministically by forcing contents.download() to fail with an unrelated error and verifying that the old broad catch continued into the editor/upload path. I also added a regression test and mutation-checked it: restoring except Exception makes the test fail.

   There is a related 404-classification problem in ContentsClient._request(): current main maps every HTTP 404 to FileNotFoundError. That means a tunnel/runtime-proxy failure that surfaces as a 404 can be presented as a genuine missing path. I do not mean that every report in this issue is proven to have that cause; the point is that current code cannot distinguish those failure classes.

   A safe fix needs both layers:

   1. distinguish runtime-proxy/tunnel authentication failures from a genuine Contents API missing-file response;
   2. have colab edit swallow only a genuine FileNotFoundError, not arbitrary download failures.

   Reference implementation and tests in my fork:

   • branch: fix/edit-download-error-narrowing
   • commit: af6fa1c5241b44052a539391f469743b6bc09a99

   Focused regression checks rerun against that commit:

   test_cli_edit_download_error_propagates
   test_cli_edit_proxy_error_propagates
   test_empty_404_raises_runtime_proxy_error
   test_401_empty_raises_runtime_proxy_error
   test_json_404_stays_file_not_found
   

   All 5 passed.

   This overlaps with the runtime-credential work in #109/#106, but I wanted to call out the colab edit overwrite consequence specifically because it turns a read/auth failure into a potential remote data-integrity problem.
2. phiiggfdg commented on Sep 26, 2026

   

   phiiggfdg

   on Sep 26, 2026

   More actions

   I reproduced this behavior and traced it to stale runtime-proxy credentials rather than the VM actually dying.

   The assignment can still be alive and an already-open console can continue working, while new commands such as colab upload, colab download, colab ls, or a new console connection fail because the CLI is still using an old runtime-proxy token / URL stored in the local session state.

   The backend returns fresh runtimeProxyInfo, but the old flow was not consistently refreshing the local session credentials. On top of that, some 401/404 proxy failures could be surfaced as misleading "file or directory not found" errors.

   I fixed this in my Android/Termux fork at the shared session/runtime-proxy lifecycle layer rather than patching upload/download individually.

   The fix now:

   • refreshes runtime-proxy credentials for long-lived sessions
   • renews credentials before expiry
   • preserves a live assignment when a stale 401/404 occurs
   • refreshes the session instead of pruning it
   • avoids treating transport/proxy failures as normal missing-file cases
   • shares the same refreshed session state across file access, execution, console reconnects, SSH, and other runtime commands

   I also added a live regression test that intentionally injects stale credentials.

   Test result:

   [SUCCESS] Phase 1 passed: expired token refreshed before file access.
   [SUCCESS] Phase 2 passed: live assignment preserved and next command recovered.
   [SUCCESS] Runtime-proxy refresh/recovery regression passed.

   If you want to test the implementation, it is here:

   https://github.com/phiiggfdg/google-colab-cli-android

   The relevant build is the latest Android/Termux version in the repo.
3. sethtroisi commented on Sep 27, 2026

   

   sethtroisi

   on Sep 27, 2026

   Collaborator

   More actions

   Stale runtime tokens were fixed in #149, If you still see this after upgrading to version 0.7.4 let us know and we'll investigate again.
4. sethtroisi

   closed this as completedon Sep 27, 2026