Release blocker. A machine restart leaves every sync engine dead, and nothing starts one again. The agent keeps working, messages keep committing locally, and nothing reaches the other machines until a person happens to type remote sync start.
session-start.sh says this in its own comment (#761):
A reboot leaves every sync engine dead and nothing restarts one
#765 made that visible — a session now warns when a connected team has no engine. Visibility was the right first step and it is not enough: the warning only appears when someone opens an agent session, and it asks the person to do something the machine could do itself.
Decided
When an agent belongs to a remote team, check whether that team's engine is running, and start it if it is not.
Two trigger points, both places where an agent already establishes what it is:
- session start — where the monitor is started today
actas — where a session takes on a role, and therefore a team
Only for teams whose binding is connected. A team that was never connected, or is disconnected, is not the engine's business.
One engine per (machine, remote team)
The mechanism already exists — use it, do not build a second one.
scripts/remote.sh
cmd_sync_start agmsg_lock_acquire "$TEAMS_DIR/<team>" per-team lock
engine_state == running
-> "Sync engine already running (pid N)." and returns
pidfile $CONNECTION_ROOT/run/remote-sync.<team>.pid per-team
So sync start is already idempotent under a per-team lock, and the invariant holds by construction. The auto-start path should call the same command and inherit that, rather than deciding for itself whether an engine exists — two places that answer "is it running?" is how the answers diverge.
The case to get right is several agent sessions on one machine starting at once, all in the same team. They will race for the lock; one starts the engine, the others must see already running and continue. That is the existing behaviour of the command, and it is what the tests need to pin.
Conditions
A failure to start must not block the session. If the engine cannot start, the session continues and says so. An agent that will not open because a sync engine refused is worse than a sync engine that is down.
Say what happened, once. Starting an engine is a side effect the person did not ask for in that moment; it belongs in the same place #765 puts its warning, in the same voice — and when it started successfully, the warning should not also appear.
Do not start anything for a team that is not connected. The check is on the binding, not on the presence of a directory.
Not in scope
sync stop and sync status, which do not exist (remote.sh sync accepts only start). They are wanted soon and are not blocking a release; they are separate because auto-start must not wait on them.
Refusals from the server that stop the engine — fujibee/agmsg#773. Note the interaction: once auto-start exists, an engine that exits on a refusal will be restarted on the next session, exit again, and restart again. #773 and this issue must not be implemented as if the other does not exist.
Release blocker. A machine restart leaves every sync engine dead, and nothing starts one again. The agent keeps working, messages keep committing locally, and nothing reaches the other machines until a person happens to type
remote sync start.session-start.shsays this in its own comment (#761):#765 made that visible — a session now warns when a connected team has no engine. Visibility was the right first step and it is not enough: the warning only appears when someone opens an agent session, and it asks the person to do something the machine could do itself.
Decided
When an agent belongs to a remote team, check whether that team's engine is running, and start it if it is not.
Two trigger points, both places where an agent already establishes what it is:
actas— where a session takes on a role, and therefore a teamOnly for teams whose binding is connected. A team that was never connected, or is disconnected, is not the engine's business.
One engine per (machine, remote team)
The mechanism already exists — use it, do not build a second one.
So
sync startis already idempotent under a per-team lock, and the invariant holds by construction. The auto-start path should call the same command and inherit that, rather than deciding for itself whether an engine exists — two places that answer "is it running?" is how the answers diverge.The case to get right is several agent sessions on one machine starting at once, all in the same team. They will race for the lock; one starts the engine, the others must see
already runningand continue. That is the existing behaviour of the command, and it is what the tests need to pin.Conditions
A failure to start must not block the session. If the engine cannot start, the session continues and says so. An agent that will not open because a sync engine refused is worse than a sync engine that is down.
Say what happened, once. Starting an engine is a side effect the person did not ask for in that moment; it belongs in the same place #765 puts its warning, in the same voice — and when it started successfully, the warning should not also appear.
Do not start anything for a team that is not connected. The check is on the binding, not on the presence of a directory.
Not in scope
sync stopandsync status, which do not exist (remote.sh syncaccepts onlystart). They are wanted soon and are not blocking a release; they are separate because auto-start must not wait on them.Refusals from the server that stop the engine —
fujibee/agmsg#773. Note the interaction: once auto-start exists, an engine that exits on a refusal will be restarted on the next session, exit again, and restart again. #773 and this issue must not be implemented as if the other does not exist.