Use the correct wires when cancelling the scry request and/or its
timers.
Note that we may produce more %rests and %yawns than strictly necessary,
but these no-op cleanly in those cases.
the full type output by vars is now:
(list [cord (list [cord (list [cord @])])])
it's a mouthful, but a consistent mouthful. the first layer of the list
is the IO driver name, nam_m. the second layer is the instance name,
either %all or some driver-relevant identifier (e.g. http instance.) the
third layer is the list of labels and values.
This actually raises difficult questions about the schema for the /vars
peel. One level of nesting makes sense to aggregate per IO driver, but
multiple levels is confusing.
The current output is extremely unprincipled: you just have to know that
there are multiple http servers and handle the output accordingly.
Options would be:
1. collapse the ambiguity to the top level, i.e. 'http-0i8080',
'http-global', etc.
2. collapse the ambiguity to the inner level, i.e. '0i8080-connections'.
3. create a proper recursive data type that e.g. uses an $each.
3b. send some kind of schema.
5. recognize that we have entered a terrifying hall of mirrors and back
out the entire approach of nested metrics in favor of just a bigass
flat list of labels with values like borgmon does.
tid was accidentally getting set to the name of the output mark. As we
don't currently support cancelling threads, there is no reason to
maintain the originally-intended correspondence between tid and conn
request-id.
Take the opportunity to clean up indentation somewhat.
This can occur after upgrade, or when receiving a %delta blob. We do not
know the path or commit timestamp of a file that resolves to the blob,
so we simply fall back to old ames-style blob-by-lobe fetching.
In +work, we simply want to fetch file data, regardless of what the
overarching request is. (In fact, %sing would likely never hit this path
anyway.)
In order to be able to make the scry request, we track the timestamp of
the commit that contains a blob we're missing, and scry for that %da
revision.
There's two edge cases where we cannot immediately know the timestamp
that are currently assumed broken. Fix soon.
