This removes the %http-response special case from gall. In its place,
we implement a subscription regime with the following steps:
- Agent sends %connect to Eyre
- Eyre pokes agent with %handle-http-response, including unique eyre-id
- Agent passes %start-watching to Eyre with eyre-id and unique app-id
- Eyre subscribes to agent on /http-response/app-id
- Agent produces a %http-response-header fact followed by 0 or more
%http-response-data facts and possibly a %http-response-cancel fact
- Agent produces a %kick to close the subscription, which Eyre
interprets as completion of the message.
This works when there is data. There is currently a bug where if the
response has no data in total (as in the case of a naked 404), no
response will be sent.
This also includes lib/http-handler, which implements a convenient
interface for agents that want to respond immediately with all the data.
This lets them avoid carrying extra state to keep track of pending
requests.
This should really have access to your state and the ability to change
it. Perhaps a more minimalist design would be better: just keep track
of the requests, then hand it off to +on-watch when eyre is ready to
receive responses. It's not clear how to pass in the request data in
+on-watch.
We were updating our state and then using that when checking if the rift
had incremented. This would never be true, since we'd already set the
new state.
Fixes#1852 again
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.
%gall currently prints
[%gall-booting <app> p=<ship> q=<desk>]
whenever it receives a %conf (i.e., when it boots an app). This turns
up in many of the places the old, less-informative '%mo-not-running'
printf did, but it's of similarly little use, and mainly serves to
create redundant line noise. This commit just removes it.
* reclamation:
solid pill
arvo: wires up %trim memory-pressure event stubs
u3: wires up the %trim event in the daemon
u3: adds %trim memory-pressure notification "effect"
u3: tweaks |mass output (and fixes inadvertent truncation)
u3: refactors periodic memory reclamation
u3: factors out u3a_idle() to measure free-lists in a road
u3: adds and uses u3a_full/heap/temp road macros
u3: cleans up whitespace, removes dead code in allocator
