mirror of
https://github.com/home-assistant/supervisor.git
synced 2025-04-21 19:57:15 +00:00
9f3767b23d
* Return cursor of the first host logs entry via headers Return first entry's cursor via custom `X-First-Cursor` header that can be consumed by the client and used for continual requesting of the historic logs. Once the first fetch returns data, the cursor can be supplied as the first argument to the Range header in another call, fetching accurate slice of the journal with the previous log entries using the `Range: entries=cursor[[:num_skip]:num_entries]` syntax. Let's say we fetch logs with the Range header `entries=:-19:20` (to fetch very last 20 lines of the logs, see below why not `entries:-20:20`) and we get `cursor50` as the reply (the actual value will be much more complex and with no guaranteed format). To fetch previous slice of the logs, we use `entries=cursor50:-20:20`, which would return 20 lines previous to `cursor50` and `cursor30` in the cursor header. This way we can go all the way back to the history. One problem with the cursor is that it's not possible to determine when the negative num_skip points beyond the first log entry. In that case the client either needs to know what the first entry is (via `entries=:0:1`) or can iterate naively and stop once two subsequent requests return the same first cursor. Another caveat, even though it's unlikely it will be hit in real usage, is that it's not possible to fetch the last line only - if no cursor is provided, negative num_skip argument is needed, and in that case we're pointing one record back from the current cursor, which is the previous record. The least we can return without knowing any cursor is thus `entries=👎2` (where the `2` can be omitted, however with `entries=👎1` we would lose the last line). This also explains why different `num_skip` and `num_entries` must be used for the first fetch. * Fix typo (fallback->callback) * Refactor journal_logs_reader to always return the cursor * Update tests for new cursor handling