Sending Tasks to Other Machines

A task can be sent from the Tasks tool to Wing on another machine, called a peer, to run there. For example, a task written on macOS can be checked or fixed on a Windows or Linux virtual machine without anyone working at that machine. What the task finds comes back to the machine that sent it, and for a change, so do its changes, where they are reviewed and committed as any task's. The peer never commits.

Peers exchange encrypted messages through a mailroom, a directory both machines can reach. No Wingware server is involved. Every Wing that uses the mailroom with its key is a peer of the others, under a peer name of its own. A peer with a working copy of the same repository can take this machine's changes and send its own back. A peer with another repository can be asked for a report, or handed work to do and commit there, as described in Peers with Other Repositories below.

Setting Up Peers

To set up peers, select Peers... from the Options menu in the upper right of the Tasks tool, in each Wing that will send or receive tasks. The project must be open in each, from a working copy of a Mercurial or Git repository with at least one commit. Setting up is naming this Wing, choosing the mailroom, and giving it the mailroom key: every other Wing in the mailroom with the same key is a peer. The dialog sets:

Peer Name -- The name other peers use for this Wing, such as mac or win-vm. It also names this Wing's directory in the mailroom, where its peers leave the tasks they send it. A peer name belongs to one working copy, also on the same machine, so two working copies on one machine need different names, for example linux and linux-web. Pressing OK with a name another Wing already has in the mailroom asks whether to take it over, as when moving a name to another working copy. Once taken over, what peers send to that name comes to this Wing, and the other Wing, if running, stops serving the name within a few minutes and says why its peers no longer see it. The field suggests this machine's host name, or the host name followed by the project file's name when another Wing already has the host name.
Machine Description -- One line that the other Wings in the mailroom show for this one, such as Windows test box, so peers can plan which tasks to send it. By default this is empty.
Mailroom -- Either Local or Shared Folder and a full Path, or Directory on an ssh Remote Host, the host, and a Path on that host. See Choosing a Mailroom below. OK makes this machine's directory in the mailroom, and the mailroom too if it is missing and the directory it is in exists.
Mailroom Key -- The key that limits which machines can send this one tasks, as described in Who Can Send Tasks below. Each mailroom has one key, so this row shows the key of the mailroom chosen above, and Generate and Paste are disabled until a mailroom is chosen. A mailroom this machine has no key for needs its key generated or pasted, even when the mailroom used before had one. Only the same mailroom, with its path typed another way, keeps the key. The key is kept once per mailroom on each machine, so every Wing on this machine that uses the mailroom has it once it is entered in one of them, and the text below the buttons names the others found there. Peers stay off on a machine without one. Generate makes a new key on the first machine, Copy copies it to paste into Peers... on each of the other machines with Paste. Once other machines are found in the mailroom, Paste comes first and Generate offers to paste their key instead. You can press OK before the key is set, to set up the mailroom first. The text below the buttons shows the key's fingerprint. While Wing looks for the project's repository, which takes a moment for a working copy on a remote host, it shows Looking for the project's Mercurial or Git repository... and the buttons are disabled. When the working copy can't be read, for example because its host can't be reached, the text says so, and Test Connection tries again.
Test Connection -- When the peer name, mailroom, or key shown is not saved yet, first saves the dialog and registers this Wing in the mailroom as OK does, making the mailroom and this Wing's directory there, but leaves the dialog open. Then it checks that the mailroom can be reached and written and that this Wing's peer name is its own there, and lists each peer found there by name, with when it was last seen and whether it has the same repository. It warns when other users can write to a local mailroom, except on Windows, where this is not checked. It also says when this machine has no mailroom key, or another machine has none or a different one, and when one runs a version of Wing that needs updating before the two can send each other everything. Sending a task that a peer's older Wing can't read fails, saying so. It reports a problem when another Wing is registered under this Wing's peer name, and lists each Wing in the mailroom that this machine's key can't read with the reason. A Wing registered in the last day that has not yet announced itself, for example one still being set up, is listed too, saying so. When this Wing's own presence could not be written, it says why.
Peers in This Mailroom -- The peers found in the mailroom, sorted by name, with each one's description, operating system, branch, when it was last seen, and its version of Wing. same repository marks each peer with a working copy of this repository. A peer with another repository that takes no requests from other repositories says so. After the peers, each Wing in the mailroom that has no mailroom key, or another one, or has not yet announced itself, has a line of its own saying why it is not a peer, with the fingerprint of any key it uses. When this Wing's peers can't see it, for example because its presence could not be written, a line at the top says why. A peer not seen for 30 days is no longer listed. Remove takes the selected peer out of the mailroom once it has not been seen for 10 minutes. It comes back if its Wing runs there again.
Inbox Goal -- The goal on the Plan tab where tasks that peers send to this machine are filed. By default this is a new goal named Peer Requests. Select None: decline requests from peers for a machine that only sends tasks. File Tasks As sets whether these tasks are Ready, which is the default, or Draft, so they wait for you to make them Ready.
Accept requests from other repositories -- Whether peers with other repositories can send this one reports and handoffs. This is checked by default. Unchecked, their requests are declined, and their Send to Peer dialog lists this Wing but can't send to it.
Mark Complete closes the peer's copy too -- Whether marking a task that crossed machines complete here also completes its copy on the peer, and the peer's Mark Complete completes the copy here. This is checked by default. Uncheck it when different people review the work on each machine. See Completing Tasks on Both Machines below for details.

These settings are stored with the project, for this machine only. The mailroom key is kept in Wing's settings directory, readable only by your user account, and is never stored in a project file or in the mailroom.

Renaming this Wing, or choosing another mailroom, takes it out of the mailroom under its old name. To leave a group of peers, clear the mailroom's Path.

Choosing a Mailroom

Every peer must use the same mailroom. Each Wing reads only its own directory in it and writes messages into its peers' directories. The mailroom can be any of these:

A shared folder -- A folder on one machine shared into virtual machines, or a share on a file server. Each machine gives the path to the folder as it sees it, for example /Users/me/WingMail on the host and Z:\WingMail on a Windows virtual machine.
A sync folder -- A folder kept in sync by Dropbox, OneDrive, iCloud Drive, Google Drive, or Syncthing. Messages arrive only as fast as the service syncs them. The service's provider can't read the tasks and changes in them, which are encrypted, but can see peer names and when each peer is active.
A directory on an ssh host -- A directory on any machine Wing can reach over ssh, which may be one of the peers or another machine. Select Directory on an ssh Remote Host and then the host, which is one of your Remote Hosts. Press New... to set one up, which Wing offers at once if there are none yet, Edit... to change the selected one, or Manage... for all of them. A new host is selected once it is saved, and Wing installs its remote agent there. Wing reaches the directory through the remote agent, so the path is on that host, either full or relative to the home directory there, and Browse... chooses it on the host, where New Directory makes one. If the agent there is too old for peers, Wing reinstalls it when you press Test Connection or OK, or send to a peer.

A Remote Host mailroom logs in with remote development's credentials: a key loaded into ssh-agent (or Pageant, or the Windows OpenSSH agent), or a password or passphrase entered once in that Wing session. A key's passphrase is shared with remote development and version control, so one entered for either is used for the mailroom too, for as long as its prompt was set to keep it. The first time Wing needs the mailroom in a session, it asks for the login if one is needed. After that it reads and writes the mailroom in the background without asking, even if you cancelled that prompt. When a login would be needed, the peer is shown as unreachable, and the login is asked for again only when ssh refuses the stored one, or when you press Test Connection, open Send to Peer..., or choose Fix Setup... for a task that can't reach the peer. While the host can't be reached, Wing tries it again in the background less and less often, down to every 15 minutes. Those three actions try it at once. For three minutes after your computer wakes from sleep, Wing tries the host again at most 40 seconds apart and does not show the peer as unreachable, since the network may not be back yet. See Setting up SSH for Remote Development for what clears stored logins.

A machine that receives tasks over ssh with no one at it, such as a virtual machine after a restart, needs to log in without a prompt. Load its key into ssh-agent when you log in to that machine, or give it a dedicated key with no passphrase that is authorized only on the mailroom's host. Otherwise it can't read the mailroom until someone enters the passphrase there. A shared folder mailroom avoids this.

Wing on each machine must be running, with the project open, to receive tasks. It records in the mailroom when it was last seen, along with the state of its working copy. With the Tasks Manager on there, Ready tasks from peers run without anyone at that machine.

Who Can Send Tasks

Tasks from peers run with the receiving machine's agents and permissions, so keep the mailroom reachable only by your own machines, with the access controls of the operating system, file server, or ssh host. For example, use a folder shared only with your own virtual machines, or a directory on an ssh host that only you log into. Give separate groups of machines separate mailrooms.

Every Wing that exchanges tasks through the mailroom needs the same Mailroom Key, whatever its repository. Peers with other repositories can send this one reports and handoffs, unless Accept requests from other repositories is unchecked. Wings that should not send each other tasks need separate mailrooms, or different keys.

Wing encrypts the tasks and changes in each message, and the working copy state each machine records in the mailroom, with the key, using AES-256-GCM. A machine declines every message not encrypted with its key. Others who can reach the mailroom, as in a shared sync folder or a file server share, can't read or change what is encrypted, or make a machine run tasks.

The key can't keep anyone who reaches the mailroom from:

Seeing peer names, when each peer is active, and the size and timing of messages.
Deleting, holding back, or delaying messages. Wing shows a task whose request is not picked up or answered, as described in When a Peer Can't Be Reached below.
Registering a peer name in the mailroom first, or taking over one in use, so the Wing that wanted it has to choose another name or take it back.

All Wings in a mailroom share one key, so Wing can't tell one of them from another. To remove a machine from the group, generate a new key and paste it on each machine that stays, or move them to a new mailroom. Wings that use the mailroom with a different key are listed after the peers in Peers..., each saying why, and exchange no tasks with this one.

A machine without a key still appears in the mailroom, so Test Connection on the others lists it, but it sends no tasks and takes none that arrive. Requests that arrive before you paste the key wait in its inbox, and Wing checks them once the key is set. When a machine can't load the encryption Wing uses, Peers... says why and peers stay off there.

When a peer's mailroom key differs from this machine's, or the peer has none, the two decline each other's tasks. The Send to Peer dialog then says so and changes Send to Send Anyway. A task sent anyway can't be read there, so it always ends up unreachable. To fix it, copy one machine's key to the other. Changing a machine's key encrypts the messages still waiting to be delivered from it again, with the new key.

To read each request before it runs, set File Tasks As to Draft in Peers....

Sending a Task

To send a task that has not started, right-click on it and select Send to Peer.... This is offered once this Wing has a peer name, a mailroom is set, and at least one peer has been found in the mailroom. The Send to Peer dialog sets:

Peer -- The Wing to run the task. The peers are listed by name, as in Peers..., with same repository on each that has this repository. The first of those is selected by default. A peer with another repository that takes no requests from other repositories is listed but can't be chosen.
Kind -- Report runs the task there and reports what it found, and any changes it makes are discarded. This is the default. Change brings its changes back to this machine as a patch, and is offered only for a peer with the same repository. Hand off files the task there as an ordinary task, whose changes stay there to be reviewed and committed by that Wing's user or its Tasks Manager. Only its report, and any returned files, come back. For a task that changes code, use Change with a peer that has the same repository, and Hand off with one that has another. Choosing a peer with another repository while Change is selected selects Hand off.
Reply due -- How long the peer has to reply once it picks the task up, from 1 hour to 1 week. After that the task counts as unreachable. By default there is no limit.
Return files to -- A directory in this working copy, relative to its root, where files the task makes for you, such as images or data, come back. Browse... chooses it when the working copy is on this machine. By default this is empty, and no files come back. See Returned Files below.

The task does not run on this machine while the peer has it. Meanwhile the Execute tab lists it in the peer's queue, named Peer: and the peer's name, such as Peer: win-vm. Wing adds this Peer queue below + Add Queue on the first send to that peer, and removes it once the peer has no tasks and their returned work is committed. Its line shows how many tasks the peer has and the state of the one that changed last, and its dot flashes while the peer runs one of them. A Peer queue has no run controls, and tasks can't be added to it.

Up Next lists the tasks that a queue sent to a peer under that queue, indented below the peer's queue name, such as Peer: win-vm. The dot beside that name flashes while the peer runs one of those tasks. The Peer queue itself is listed last, with only the tasks that no queue sent, such as those you sent yourself.

A task sent from another queue is left out of that queue's list while the peer has it. The queue's line says how many of its tasks are away instead, such as 2 on win-vm, and clicking on that shows the Peer queue. The count on the Execute tab includes the tasks running on peers. The Tasks Manager can also send tasks to peers; see The Tasks Manager and Peers below.

Freshness and Carried Changes

For a peer with the same repository, the dialog shows before sending how the peer's working copy compares with this one, from what the peer last recorded in the mailroom. For example: win-vm: dev-beta at a1b2c3d4e5f6, 4 changesets behind; differs in launch-env.bat (named by the task) and 6 other files. The files counted are those that differ between the peer's working copy parent and this working copy, so they include both unpushed commits and uncommitted changes here. A peer that holds commits this repository lacks is shown as being with commits we don't have, and its differing files can't be counted. Peers that are behind, ahead, or have other commits are common, and are not warned about.

When the peer's copy differs in files the task names, checking Include my changes sends this machine's changes to those files with the task. The peer's Wing applies them to its working copy before the task starts, so they are not counted as the task's own changes, and reverts them once the task's work is back here, or the task is taken back. The checkbox is checked whenever those changes can be carried. When only files the task does not name differ, the checkbox is left unchecked, and checking it sends the changes to all of them. The changes keep each file's executable bit, except on Windows, which has none.

The changes can't be carried when the peer holds commits this working copy lacks, is on another branch, uses another version control system, or has uncommitted changes in the same files. When this affects files the task names that have changes here, the dialog names those files and says why, and Send becomes Send Anyway, which sends the task without the changes. To run the task on current code instead, update the peer's working copy first, by pulling and updating there, and then send. Send Anyway suits a task that does not depend on the changes, such as a probe of the peer's environment. Changes over 14 MB can't be carried at all, and sending the task with them fails, saying so.

On the Receiving Machine

Wing checks each message before any agent sees it. A message from a Wing not found in the mailroom, one that this machine's mailroom key can't decrypt or that was changed, or one that repeats an earlier one is declined without an answer. Wing waits a few minutes before declining a message from a Wing it hasn't found, so a peer that just joined is found first. A message dated ahead of this machine's clock is accepted, so a peer whose clock is wrong loses nothing. A request that tries to set what only the receiving machine decides, such as its permissions, tools, or whether to commit, is declined, and the sender is told why.

Wing files each accepted request as a task in the inbox goal set in Peers..., as Ready or Draft. It runs autonomously, as Decide and Report, with the receiving machine's own permissions. A task from a peer is never committed here, except a handoff, as described in Sending a Task above. When the task finishes, Wing sends the task's report and, for a change, its changes back to the requesting machine. When this working copy is no longer at the revision the requesting machine saw here, or made its carried changes for, the task's text ends with a warning that files may not be as the requesting machine expects.

Requests whose carried changes touch the same files take turns. A later request is filed as a Draft and held until the earlier request's carried changes are reverted here. Wing then applies its changes and makes it Ready, or leaves it a Draft, as File Tasks As says. A request is also held while the files its changes touch have unsaved changes in an editor here. To apply a held request's changes without waiting for an earlier request, click its Held chip, on Plan or the Questions tab, or right-click the task on Plan, and select Apply Carried Changes Now. The earlier request's revert then leaves those files as they are. Unsaved changes still have to be saved or discarded first. A held task started by hand runs without its carried changes. When a held request's changes no longer apply once it is released, Wing declines it.

Once the work has been sent back, Wing reverts the changes of a report or change task, and any changes carried with the request, in its working copy. For a report this happens at once; for a change, once the requesting machine has applied the patch or kept it. A file changed since the task started is left as it is. When the requesting machine takes a task back, Wing stops the task if it is running, as Cancel would, adds a line to the task saying why it stopped, and the task's chip shows Cancelled. The work done so far is left in place, and the changes carried with the task are reverted once it stops. A task that has not started becomes a Draft.

When the Work Comes Back

Wing applies a returned patch to this working copy with a three-way merge. The files it changes become the sent task's changes, and the task moves to the Review tab, where it is reviewed, tested, and committed as usual. It goes back to the queue it was sent from, and a task sent from no queue is placed in the Peer queue. The Tasks Manager puts each task it sends from no queue into one of its own queues first, so it commits the work as its commit policy says.

The patch also carries the task's changes to each file's executable bit. The task's report names any file the peer could not carry back, because it is binary or too large, or because other work on the peer changed it too. When the task's changes come to over 20 MB, none are sent back: the report says so, and the changes are left in place on the peer.

When the patch conflicts with changes made here since the task was sent, Wing saves it as a .diff file and files a Ready task, in the sent task's goal, for an agent to merge it. The sent task is then done by the merge task, and goes to History once the merge task reaches Review. If the merge task is deleted or made a Draft, the sent task becomes a Draft, with a note naming the .diff file, which is kept, so the peer's work is not done again here unless you make it Ready. Making the merge task Ready again puts the sent task back in its hands. When the merge task can't be filed, the patch waits on you as described next.

When the patch touches a file with unsaved changes in the editor, applying it fails, or its merge task can't be filed, an item on the Questions tab lists it. For unsaved changes, save or revert the file and then press Apply Again. After a failure, Apply Again tries again once the cause is fixed. Until then the task's Ready or Draft marker on the Plan tab opens the Questions tab when clicked. The item also offers:

Apply with Conflict Markers -- Apply the changes, marking each conflict for you to resolve, and send the task to Review.
File a Merge Task -- Save the changes as a .diff file and file a Ready task for an agent to merge them.
Keep the Patch Only -- Save the changes as a .diff file and apply none of them. The task goes to Review with its report.

The .diff files are saved in the research notes directory, set in Tasks Manager Settings... in the Options menu, with names that start with peer-patch- and the peer's name.

Returned Files

When Return files to names a directory, the task on the peer is told to write the files it makes for you to .TASKS/peer-out/ in its working copy, in a directory for the request. That directory is never committed or reverted there. The reply carries its files, binary files included, and Wing writes them into the named directory here, for any kind of task and any peer. Wing then removes them on the peer.

The returned files become the sent task's changes, and it goes to Review as for returned work. A returned file that conflicts with one changed here takes the same path as a patch that conflicts, described in When the Work Comes Back above. Returned files share the 20 MB limit on a task's changes, and the task's report names those left behind.

The peer keeps the files it returned for 14 days, or until this machine has them, so Send Reply Again sends them too.

Completing Tasks on Both Machines

Once its work has come back, a task can be on the Review tab on both machines, as for a handoff: the requesting machine's copy with the report, and the peer's with its changes. By default, Mark Complete on either copy tells the other machine, which moves its copy to History too.

A copy with changes to commit stays on Review, so the work is never lost or committed without you. This holds for a returned patch applied here and for a handoff's changes on the peer. A copy that is being reviewed, or that the Tasks Manager commits itself, also stays. Its chip's tooltip then says when the work was marked complete on the other machine. A commit on one machine never completes the other's copy.

Either machine can turn this off by unchecking Mark Complete closes the peer's copy too in Peers.... It then neither closes the peer's copies nor lets the peer close its own. A peer that runs an earlier Wing is not told, and its copy stays on Review.

Peers with Other Repositories

A peer with another repository runs a task in its own working copy. When one is chosen in the Send to Peer dialog, its intro says that the peer's Wing runs the task in its own repository and what comes back. A note reminds you to write the task for someone without this repository: what to do and find there, rather than which of this repository's files to change. Below that, the dialog shows the peer's operating system, branch, and description, in place of how fresh its working copy is.

Only Report and Hand off can go to a peer with another repository. No changes go from this working copy to it, so Include my changes is hidden, and no patch comes back from it. A Change request from a peer with another repository, or one with changes, is declined on arrival, as is every request from another repository when Accept requests from other repositories is unchecked.

The task filed on the receiving machine says that it comes from the sending peer's Wing, which lacks this repository, so paths it gives are its own.

Peer Chips

A teal chip marks each task that crossed machines, on its row, on its Questions tab items, on Review, and in History:

→ win-vm -- A task sent from here, followed by its state and the time it got there. It is Sent, then Accepted once the peer has filed it, and then where the task is on the peer: Draft there, Queued there, Running, Interrupted there, Waiting on its user, Finished, or Reply sent. It shows Reply missing or No reply yet when the reply is overdue, Unreachable while the peer can't be reached or the request waits to be delivered, and Declined or Dropped when the peer declined the task or ended it unanswered. Once the work is back it shows Returned, or Returned, waits on you until you decide on a patch that did not apply. On Review, a task whose work came back shows Made on win-vm.
← mac -- A task filed here from a peer's request. It shows Held while the changes carried with it wait to be applied, as described in On the Receiving Machine above, and hovering says why, or Cancelled once the peer has taken it back.

The header of the inbox goal for peer requests shows ← and the names of its peers, as does the line of a queue on the Execute tab while it holds unfinished tasks from their requests. Hovering over a chip shows the task's whole exchange: when it was requested, picked up, and answered, its reply deadline, how fresh the peer's copy was, and which changes were carried. The Classic look colors the text instead of drawing a chip.

When a Peer Can't Be Reached

A sent task counts as unreachable when the mailroom can't be reached or needs a login, or the peer has not been seen for 10 minutes. It also does when the peer's mailroom key differs from this machine's. Finally, it does when the peer has not picked the task up within 5 minutes of sending, or has not replied by the Reply due time.

Until Wing has seen a peer write to the mailroom, it knows when the peer was last seen only by the peer's clock, and the reason says by its clock. Wing then waits 5 minutes before counting the peer unreachable, in case only the peer's clock is behind.

A request sent while the mailroom can't be reached waits on this machine and is delivered once it can be. A request still undelivered after 29 days is dropped. A task the peer picked up with no Reply due time shows No reply yet once a day passes without a reply, and is not counted as unreachable.

Wing keeps waiting for an unreachable peer. It goes on delivering waiting requests, checking whether the peer is back, and picking up replies that were held up, until the peer answers or you act. The task's chip shows Unreachable, and hovering over it shows the reason, such as Can't reach the mailroom's host.

Clicking the chip of a task that is with a peer, or right-clicking its row, shows these choices, whether or not the peer can be reached:

Fix Setup... -- Try again now, asking for a login where one is needed, and open the Peers dialog with the failing check named. This is shown only while the peer can't be reached.
Send to Another Machine -- Take the task back and send it to another peer, chosen from a submenu.
Run Here Instead -- Take the task back and make it Ready to run on this machine.
Take Back as Draft -- Take the task back as a Draft.
Mark Complete -- Take the task back and move it to History, for example when its work was done some other way.
Delete -- Take the task back and delete it. Deleting the task in any other way, such as with its row's delete icon or with its goal, does the same.

Taking a task back removes a request the peer has not picked up yet, and otherwise tells the peer to cancel it, which stops the task there if the peer has started it. The task is yours again at once, and hovering over the chip or the choices says when the peer has started it. A request dropped from this machine's outbox after 29 days is listed on the Questions tab, with Send to Another Machine..., Run Here Instead, and Take Back.

When a peer declines a task, for example because it takes no requests, the task becomes a Draft and the Questions tab lists it with the peer's reason. When the peer declines it because the changes carried with it no longer apply there, Wing first sends it once more, with this machine's changes as they are now, and lists it only if that is declined too or can't be sent. A peer that deletes the task, or marks it done without replying, drops it: its chip shows Dropped and the Questions tab lists it in the same way. The choices are Send to Another Machine..., Run Here Instead, and Take Back.

When a peer finished a task over 10 minutes ago and its reply still hasn't arrived, its chip shows Reply missing, and Wing keeps waiting as for an unreachable peer. A peer that was closed while replying sends its reply once its project is opened again.

When a reply was lost, for example because someone removed it from the mailroom, right-click on the task on the peer's Review or History tab and select Send Reply Again. Wing sends the task's report again, with any change it returns, until the requesting machine has applied that change, and with any returned files it still keeps. The requesting machine ignores a reply it already has.

The Tasks Manager and Peers

The Tasks Manager sends a task to a peer when the task needs that machine, for example to run on its operating system, or when you ask it to. It uses its send_to_peer tool, which works as the Send to Peer dialog does and takes these options:

peer -- The peer's name. The Manager's list of peers gives each one's description, operating system, whether it has the same repository, and the kinds it takes, so it can choose which to ask.
kind -- report, the default, change, or handoff, as Kind in the dialog.
deliver_to -- The directory returned files come back to, as Return files to in the dialog.
include_changes -- auto, the default, includes this machine's changes to the files the task names, when the peer's copy lacks them and they can be carried. yes includes the changes to every file that differs, and no includes none.
send_anyway -- Sends even when the peer has not been seen lately, and the request then waits in the mailroom until the peer is back. It also sends when the peer's mailroom key differs, though the task then ends up unreachable, and when this machine's changes can't be carried as include_changes asks, and then sends none of them.
check_only -- Reports how fresh the peer's copy is and sends nothing.
reply_due_hours -- Sets how long the peer has to reply, as Reply due does in the dialog.

When the task's files differ on the peer and the changes can't be carried, send_to_peer refuses to send it and gives the reason. The Manager then asks you on the Questions tab whether to update the peer's copy first or send anyway. It also refuses a peer that has not been seen lately, and the Manager sends the task to another peer, runs it here, or asks you. It refuses a peer whose mailroom key differs too, and the Manager sends the task elsewhere, runs it here, or asks you to fix the keys or send anyway. The Manager never resends a task the peer can't be reached for, declined, or dropped. Wing keeps waiting for an unreachable peer, and you choose what to do with a declined or dropped task on the Questions tab.

When a handoff comes back blocked, asking questions, or failed, the Manager can answer it in place. Its message goes to the task on the peer, which runs again there, and the task's new report replaces the first one here. While it runs there, its chip here says Running. A peer that runs an earlier Wing can't take such a message, so the Manager sends the work again as a new task.

See Trust Peer Machines in AI Agent Safety for what a peer can and can't do on the other machines in its mailroom.