(1) In `+thread-fail`, `+thread-clean` is called before `+thread-http-fail` and `+cancel-scry` meaning neither of the latter two actually. `serving` has been replaced with `(~(del by serving.state) tid)` in the state and therefore we cannot `(~(get by serving.state) tid)` in `+thread-http-fail` or `+cancel-scry`.
(2) In `+thread-http-fail` return an informative tang as json instead of an empty 500 http response when the failure results from an internal crash.
Include and render identities associated with requests, channels, and
login sessions. Provide the ability to kick identities and their
sessions, logging them out.
It is no longer guaranteed that the src.bowl for incoming HTTP-related
events is equal to our.bowl. Instead, it will reflect the identity
associated with the request, our or otherwise.
When serving publicly-accessible endpoints, the assertion never made
much sense, but with recent changes actively prevents guests from
accessing the endpoints. Here, we correct all such cases.
Prevously we were tracking remote scry requests using a map, assuming
that every thread would do just one remote scry request. This is not
right. A thread that did multiple +keen:strandio was treated as
if just the last call existed, overwritten previous entries in the map.
Now we track remote scries using a jug that accounts for multiple %keen
tasks per thread.
The logic for sending %yawns to %ames has been updated for the following
scenarios:
- +thread-fail will always send a %yawn task
- +thread-done doesn't send %yawn tasks
- unless a running thread is stopped
- if %spider is reloaded:
- %yawn tasks will be sent for any running or starting thread
/lib/strandio also removes +take-tune from +keen, decoupling
sending %tasks and receiving %signs. This allows for clients
to request multiple paths at future cases, without blocking.
%spider will send a %yawn task to ames if a thread fails
or stops. if the thread is done, it will delete the scry
from its state without notifying %ames
Dill's new %logs endpoint can be used to receive system output as $told
nouns. Dill no longer prints system output itself, leaving the display
of it up to terminal handlers (or the runtime). For now, to maintain the
status quo, drum subscribes to dill %logs, and prints them inline in the
default session.
Dojo had also been incorrectly updated, assuming the type of
%lens-command changed to match. Since lens should only ever be used for
running commands on the local ship (and even that being contentious (; ),
we simply auto-fill the sole session id with the local ship name.
PR #5840 mostly fixed#1559, but introduced a new bug. before, you could safely `=dir` into a desk without a case, and it would use the nonexistent case `ud+0` as the beam for dojo state, and switch that out for da+now whenever it tries to resolve the current path. but this check causes it to fail, because `ud+0` is a nonexistent case. this uses he-beam to transform the beam in the conditional to see if the case is 0, and if it is, changes the case to da+now before it scries
This allows you to pass a thread directly into khan, instead of passing
a filename. This has several implications:
- The friction for using threads from an app is significantly lower.
Consider:
=/ shed
=/ m (strand ,vase)
;< ~ bind:m (poke:strandio [our %hood] %helm-hi !>('hi'))
;< ~ bind:m (poke:strandio [our %hood] %helm-hi !>('there'))
(pure:m !>('product'))
[%pass /wire %arvo %k %lard %base shed]
- These threads close over their subject, so you don't need to parse
arguments out from a vase -- you can just refer to them. The produced
value must still be a vase.
++ hi-ship
|= [=ship msg1=@t msg2=@t]
=/ shed
=/ m (strand ,vase)
;< ~ bind:m (poke:strandio [ship %hood] %helm-hi !>(msg1))
;< ~ bind:m (poke:strandio [ship %hood] %helm-hi !>(msg2))
(pure:m !>('product'))
[%pass /wire %arvo %k %lard %base shed]
- Inline threads can be added to the dojo, though this PR does not add
any sugar for this.
=strandio -build-file %/lib/strandio/hoon
=sh |= message=@t
=/ m (strand:rand ,vase)
;< ~ bind:m (poke:strandio [our %hood] %helm-hi !>('hi'))
;< ~ bind:m (poke:strandio [our %hood] %helm-hi !>(message))
(pure:m !>('product'))
|pass [%k %lard %base (sh 'the message')]
Implementation notes:
- Review the commits separately: the first is small and implements the
real feature. The second moves the strand types into lull so khan can
refer to them.
- In lull, I wanted to put +rand inside +khan, but this fails to that
issue that puts the compiler in a loop. +rand depends on +gall, which
depends on +sign-arvo, which depends on +khan. If +rand is in +khan,
this spins the compiler. The usual solution is to either move
everything into the same battery (very ugly here) or break the
recursion (which we do here).
Before this, the %watch to eth-watcher was happening before the %poke,
and so eth-watcher was responding with its entire history immediately.
This is bad because it takes a lot of memory to process that many logs,
and also because those logs are stale.
Now, the %poke happens first, which clears the history.
%kick is supposed to start back from the snapshot and move forward.
Without this, we would only fetch logs that we hadn't already fetched.
Thus, if you were up-to-date when you kicked, you would miss anything
that happened between the time the snapshot was taken and the present,
though you would see things after the present.
Also reverted lull change to make this a safer upgrade.
Previously, the initial Azimuth snapshot was stored in Clay and shipped
in the pill. This causes several problems:
- It bloats the pill
- Updating the snapshot added large blobs to Clay's state. Even now
that tombstoning is possible, you don't want to have to do that
regularly.
- As a result, the snapshot was never updated.
- Even if you did tombstone those files, it could only be updated as
often as the pill
- And those updates would be sent over the network to people who didn't
need them
This moves the snapshot out of the pill and refactors Azimuth's
initialization process. On boot, when app/azimuth starts up, it first
downloads a snapshot from bootstrap.urbit.org and uses that to
initialize its state. As before, updates after this initial snapshot
come from an Ethereum node directly and are verified locally.
Relevant commands are:
- `-azimuth-snap-state %filename` creates a snapshot file
- `-azimuth-load "url"` downloads and inits from a snapshot, with url
defaulting to https://bootstrap.urbit.org/mainnet.azimuth-snapshot
- `:azimuth &azimuth-poke-data %load snap-state` takes a snap-state any
way you have it
Note the snapshot is downloaded from the same place as the pill, so this
doesn't introduce additional trust beyond what was already required.
When remote scry is released, we should consider allowing downloading
the snapshot in that way.
