It's hard to say what's the safest thing to do when we get an ack we
weren't expecting due to losing outstanding.agents.state in +load
3-to-4, so this gives both a watch-ack and a poke-ack. This seems most
likely to succeed.
Does not change state type, but clears outstanding.agents.state since
it's full of garbage values. This introduces a possibility that we may
have been in the middle of something, so we handle that in a reasonably
sane way.
outstanding.agents.state is a queue of what sort of message we sent to a
foreign app. We use it so that when the acknowledgment comes back we
know whether to treat it as a watch-ack, poke-ack, or neither. We used
to put this info in the wire, but this gave us a different ames flow,
which meant %leave and %watch didn't get associated (causing #2079).
The error was that when when retrieving the item from the queue, we put
the new 1-item-shorter queue back in outstanding.agents.state at a
different wire than it came from, so the queues never actually got
shorter, and acknowledgments of the wrong sort were commonly produced.
This caused problems mainly in situations where we poke and peer on the
same wire, and possibly when a subscription was cancelled.
Possibly related to #2206 and #2176. I would expect this bug to cause
those issues, but I haven't verified the converse. Also possibly
related to #2153 and #2079.
Uses Zuse's previously unused +harden helper function to streamline
+task unwrapping in vanes.
(Arguably, in landlocked vanes like Ford, we should crash if we get a
%soft task, since no events should be coming in directly from the
outside.)
Instead of providing a (unit path), allows for (list path), which better
supports the "update to path and subpath cases".
For example, if /things wants updates about everything, and
/things/specific wants updates about the specific thing, they'll both
need to receive a %fact when the specific thing changes.
Previously, these would have been two separate moves. Now, gall handles
the multi-targeting for you.
OTAs commonly end up in an inconsistent state if apps depend on changes
to /sys. For example, the %sift changes break on OTA because %spider
needs to be reloaded so that it's aware of the new thread type. This
adds a %goad app, which reloads all apps after every change to /sys.
Getting this to start OTA is nontrivial, but this pattern should work
for apps in the future. The changes to clock shouldn't generally be
necessary; they are only necessary here because we can't rely on hood to
start goad, since hood fails to compile if it's run before zuse is
reloaded. Once goad is active, this will cease to be a problem.
%leave over the network didn't work because we included the message type
in the wire from gall, so the duct for the initial %watch and the %leave
were different. We need to know the message type so we can route the
acknowledgment as %poke-ack, %watch-ack, or no-op.
This moves this piece of information to a piece of state, where we queue
up the message types per [duct wire]. Ames guarantees that
acknowledgments will come in order.
This also includes an easy state adapter. The more interesting part of
the upgrade is that we likely have outstanding subscriptions with the
old wire format. The disadvantage of storing information in wires is
that it can't be upgraded in +load. So, here we listen for updates on
the old wire format, and when we get them we kill the old subscription,
so that it will be recreated with the new wire format.
As an aside, this is a good example of what we mean when we say
subscriptions may be killed at any time, so apps must handle this case.
Finally, this fixes the "attributing" ship to ~zod for agent requests.
This information was ignored for agent requests, but including it causes
spurious duct mismatches.
Compare +mute and +mule. Those pass through scry, which doesn't allow us to
catch crashes due to blocking scry. If you intercept scry, you can't preserve
the type polymorphically. By monomorphizing, we are able to do so safely.
This broke when %kick was handled by resubscribing on your own ship
because it processed the %kick before the %leave. For example, `@t`404
at the dojo would put the dojo in an unworkable state.
You want the %leave to be processed first because you can't do a
"resubscribe" in response to that.
Until now, clients of Jael have had to store the first-seen rift if they
want to reliably detect breaches. Otherwise, they would get a false
positive if they heard an old message about a breach (eg if you kick
azimuth-tracker). Clay and Gall did this correctly, but Ames did not.
Jael already maintains this state, so I added a notification to the
existing subscription that happens whenever it notices a breach (a diff
or full where the new rift is greater than the old one).
Because this is an issue on the live network, I wrote state adapters
for Gall and Clay. The Gall one just removes the rift from our state,
but the Clay one is much more involved because we have to upgrade
instances of the clad monad that are possibly in progress.
Specifically, since more input is possible than before, we must wrap any
in-progress instances of the monad in a function that handles the
potential new input from Jael. This temporarily preservers a copy of
the old kernel, but only until the current commit/merge/update has
completed.
The real solution for Clay is to factor out those IO-heavy instances to
userspace tapp/async/imp/threads, and if an upgrade happens in the
middle, you should simply restart them.
Fixes#1852
fc7901d2 refactored much of +ap-peek, but introduced a bug in the
process. The relevant diff from that commit is as follows:
- =/ =path [ren tyl]
- =/ =vase !>((slag p.u.cug path))
- (ap-slam q.u.cug p.arm vase)
+ =/ index p.u.maybe-arm
+ =/ term q.u.maybe-arm
+ =/ =vase
+ =/ =path [term tyl]
+ =/ raw (slag index path)
+ !> raw
+ (ap-slam term p.arm vase)
Note that [ren tyl] was replaced with [term tyl], where 'term' and 'ren'
are not equal. This commit merely rights that wrong.
