plimsoll trainer · 10 / advice from the call log
An agent adds up a column by fetching 128 rows one at a time. The
agent cannot see the waste; it wrote a loop that works. The customer's API cannot see
it; it served 128 valid requests. The broker in the middle saw all
128: it is the part of plimsoll that makes each API call for the sandboxed code,
after checking the call against the run's grant, its permission to call
listed routes of one API. Because it was already checking each call, it saw each one's
route template (the allowed route it matched, such as GET /items/*) and
timing. The advisor reads that record after the run, and uses metadata and nothing
else.
The rows below are what a run's call trace holds: the broker's log of the calls the run made. A detector is a rule that looks for one wasteful pattern in those rows and reports it as a finding. This page computes the finding itself, with the detectors' rules: only calls the broker delivered with a 2xx status count, the severity rises with the count, and the cost compares the pattern with one ideal call.
Pick a run, and pick what the run's grant profile, the named grant
stored on the server, knows about a collection route (a route such as
GET /items that returns every item in one call). The profile can say, in
its batch_of setting, that one call to GET /items returns
what the calls to GET /items/* did. That is the operator's statement:
plimsoll cannot check it, because the trace holds no response bodies, so it cannot see
whether the route returns every page, the same fields, or the same items. A profile
may also list the API's full set of routes in its catalog, including ones the grant
leaves out.
The run
What the profile knows about a collection route
The struck-through rows are not redacted; a trace row has no field for them at all. So nothing built from the trace can hold them either, whether a finding, the hint returned to the caller, the audit record or the metrics.
GET /items/*: the string from the profile the operator (whoever runs plimsoll) wrote, never the path the guest, the code in the sandbox, sent.Denied, Shed, DroppedCounts kept beside the rows: calls refused by policy (over the budget, a route not on the list, or too large); calls shed, refused at once without reaching your API, while it recovers from a 429 or 503; and calls past the 256-row cap, which makes a count say "at least"./items/8813 is never recorded; only the template it matched.The one thing that answers "so you just record less". A caller may put
its own trace_id on the run, an ID plimsoll never interprets; the daemon
copies it onto the run's audit line and does nothing else with it. The path and the
body then exist in exactly one place, one layer up, in the caller's own log, and the
two logs can be joined on that ID. That is the difference between recording less and
recording only the part that is ours.
Two profile settings, independent of each other. advice decides who
sees findings they can act on; advice_retention decides what is written to
the audit log the operator keeps. plimsoll stores nothing itself, so retention is about
what it writes out.
advice
advice_retention
The advisor watches real customer traffic. Each line below is a property the code has by construction; untick one and name what it would let through.