Skip to content

exo.sh: reuse the logged ExoChat URL when the runner is up - #253

Open
aktanazat wants to merge 1 commit into
exoharness:mainfrom
aktanazat:fix/exochat-url-on-relaunch
Open

aktanazat wants to merge 1 commit into
exoharness:mainfrom
aktanazat:fix/exochat-url-on-relaunch

Conversation

@aktanazat

Copy link
Copy Markdown

Problem

show_exochat_url_if_needed only looks at adapter log lines written after the current launch started, then polls once a second for 30 seconds. That is right when exo.sh starts the adapter runner, because the exochat worker prints its URL on startup.

It is wrong when ensure_adapters finds the runner from an earlier launch still alive and returns without restarting it. No worker starts, so no new URL is printed. Every relaunch of the canonical template waits the full 30 seconds and then prints:

Waiting for ExoChat URL in /path/to/exo/.exo/exo-adapters.log...
No ExoChat URL found yet. Watch the adapter log with: tail -f /path/to/exo/.exo/exo-adapters.log

The URL was in that log the whole time. The exochat worker persists its channel and secret in session.json under the adapter state dir, so the URL it printed on an earlier launch is still the current one.

Fix

Record in ensure_adapters when it reused a live runner. In that case read the last ExoChat URL already in the log instead of waiting for a new one.

The awk block now keeps the last match rather than the first, so a fresh runner that appends a new URL below an older adapter's URL still shows the new one.

Reproduction

Runs show_exochat_url_if_needed as extracted from exo.sh against a log that already holds a URL, with start_line set to the current line count the way run_repl passes it. Case A is a relaunch with a reused runner. Case B is a fresh runner that appends a new URL after 2 seconds, below an older adapter's URL.

Before this change:

=== A relaunch, runner reused (ADAPTERS_ALREADY_RUNNING=true, start_line=4) ===
Waiting for ExoChat URL in .../exo-adapters.log...
No ExoChat URL found yet. Watch the adapter log with: tail -f .../exo-adapters.log
--- elapsed: 30s

=== B fresh runner, new URL appended after 2s (start_line=4) ===
Open this ExoChat URL in a browser or on your phone:
https://exochat.example/c/new-adapter-url
--- elapsed: 2s

After:

=== A relaunch, runner reused (ADAPTERS_ALREADY_RUNNING=true, start_line=4) ===
Open this ExoChat URL in a browser or on your phone:
https://exochat.example/c/old-adapter-url
--- elapsed: 0s

=== B fresh runner, new URL appended after 2s (start_line=4) ===
Open this ExoChat URL in a browser or on your phone:
https://exochat.example/c/new-adapter-url
--- elapsed: 2s

The full harness is 60 lines of bash and I can attach it if that is useful.

Notes

show_signal_qr_if_needed keeps its start_line window. A Signal linking QR is single use, so reusing an old one from the log would be wrong.

This touches show_exochat_url_if_needed, which #182 also edits. The hunks are different, mine changes start_line and the awk block while #182 changes the printed copy, so either order should merge with at most a trivial conflict.

Test plan

  • /bin/bash -n exo.sh
  • Reproduction above, both cases, before and after

show_exochat_url_if_needed only looks at adapter log lines written after
the launch started, and then polls for 30 seconds. That is right when
exo.sh starts the adapter runner, because the exochat worker prints its
URL on startup.

It is wrong when ensure_adapters finds the runner from an earlier launch
still alive and returns without restarting it. No worker starts, so no
new URL is printed, and every relaunch of the canonical template waits
the full 30 seconds and then prints:

  No ExoChat URL found yet. Watch the adapter log with: tail -f ...

The URL is in the log the whole time. The exochat worker persists its
channel and secret in session.json, so the URL it printed on an earlier
launch is still the current one.

Record in ensure_adapters when it reused a live runner, and in that case
read the last ExoChat URL already in the log instead of waiting for a
new one. The awk block now keeps the last match rather than the first,
so a fresh runner that appends a new URL after an older adapter's URL
still shows the new one.

Assisted-by: Claude Fable 5.1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant