It appears that bb8ba24 merged changes to /ted/test from #6790 and #6896
incorrectly, as the thread no longer compiled.
Because the former PR included the change made to the latter (printing
with slog priority 3 in case of failure), the minimum viable fix is
taking the contents of /ted/test from #6790 and using those as-is.
However, that had hidden success prints behind a "quiet" flag, and
provided no way of configuring that from outside the thread. So
additionally, we expand the ""vase parsing"" performed on the thread's
argument, such that an optional _first_ parameter of a quiet=? may be
passed.
It appears that bb8ba24 merged changes to /ted/test from #6790 and #6896
incorrectly, as the thread no longer compiled.
Because the former PR included the change made to the latter (printing
with slog priority 3 in case of failure), the minimum viable fix is
taking the contents of /ted/test from #6790 and using those as-is.
However, that had hidden success prints behind a "quiet" flag, and
provided no way of configuring that from outside the thread. So
additionally, we expand the ""vase parsing"" performed on the thread's
argument, such that an optional _first_ parameter of a quiet=? may be
passed.
We always update the eauth endpoint based on new logins from the local
identity. We also let the user configure a hardcoded endpoint url. In
both cases, we update a recency timestamp for the endpoint, to help us
keep our scry namespace responses immutable.
However, we even updated this timestamp if the visible endpoint didn't
change. That is, if the new value was identical, or if the auto-detected
endpoint changed, but it was actively being overridden by a
user-configured url.
Here, we update the stored timestamp only if the visible url actually
changed. This should help us respond to (remote) scry requests more
consistently.
(See also the note in +send-keen.)
Eyre already looks at the Forwarded header for the original requester's
IP address, and the security level of the connection. Some proxies may
modify the original Host header, but still provide the original in the
Forwarded header. So, if present, we respect that.
Now support scrying into eyre to retrieve & display its known cache
entries.
Also adds a little extra logic that lets the dbug agent send cache clear
commands on the user's behalf.
To avoid needlessly long scrolling, we add an "open" property to the
debug dashboard's SearchableList, which can be set to false to collapse
the list by default. This is useful for eyre's debug page, which
commonly contains very long lists.
Include the cached responses in their own named mass section, and add a
scry endpoint that produces the entire current cache.
A follow-up commit will leverage this for showing it in the debug
dashboard.
The restructuring in #6852 put everything under versioned scry paths.
Arvo remains none the wiser and still happily scries for /whey, without
a leading version number, resulting in loss of detail for gall's section
in |mass output.
Here, we simply slap the current version number in front of the /whey
scry path, to get it to resolve.
If the cache entry for any given url was cleared, eyre would recognize
that an entry was bound at some point in the past, and serve a 404,
instead of falling back to the normal, cacheless, dynamic response.
Here, we make eyre serve from the cache only if there is a full cache
entry for the url, and have it proceed into normal request handling
logic otherwise.
This way, setting a cached response for some url no longer means giving
up dynamic responses on that url for the rest of time.
Recent versions of vere exhibit the same behavior. As such, in practice,
this code won't get hit without a similarly-patched version of the
runtime.
