Skip to content

Add container log retrieval options#1592

Open
chrisgeo wants to merge 1 commit into
apple:mainfrom
full-chaos:feat/chaos-1322-log-options
Open

Add container log retrieval options#1592
chrisgeo wants to merge 1 commit into
apple:mainfrom
full-chaos:feat/chaos-1322-log-options

Conversation

@chrisgeo
Copy link
Copy Markdown
Contributor

@chrisgeo chrisgeo commented May 23, 2026

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

Motivation and Context

Add a source-compatible log options API for ContainerClient.logs so API clients can request recent log output and forward timestamp preferences through the existing XPC log route.

External orchestrators that implement compose-style log commands need --since and --timestamps behavior without replaying and filtering the full log stream downstream. This change introduces ContainerLogOptions, preserves the existing logs(id:) default behavior, and plumbs the options through the client, XPC harness, and container service.

The since option filters ISO-8601-prefixed lines before file handles are returned. Lines without a parseable timestamp are preserved. The timestamps option is forwarded through the API boundary as a hint; decorating raw log lines that lack timestamps remains future work.

Resolves #1591.

Testing

  • Tested locally
  • Added/updated tests
  • Added/updated docs

Local verification:

  • swift build
  • swift test --filter ContainerLogsTests
  • swift test --filter ContainerLogOptionsTests
  • LSP diagnostics clean on all changed Swift files
  • External Swift package driver imported ContainerResource, encoded/decoded ContainerLogOptions, and verified .default values

@chrisgeo chrisgeo force-pushed the feat/chaos-1322-log-options branch from 968134b to 77a21ed Compare May 23, 2026 19:52
…ient.logs

Adds an additive overload to ContainerClient.logs that accepts a
ContainerLogOptions { since: Date?, timestamps: Bool } and plumbs the
two parameters through XPC into the daemon's existing log-handle path.

Motivation
----------

External orchestrators that drive the API server (the canonical use
case is a Compose-spec orchestrator implementing 'compose logs --since
<timestamp>' and '--timestamps') need to retrieve only recent log
output and optionally annotate lines with timestamps. Today
ContainerClient.logs(id:) returns raw containerLog + bootlog file
handles unconditionally; consumers either replay the entire log buffer
or implement their own line-by-line filter on the client. Surfacing
the parameters at the API boundary keeps the line scanning where the
file lives — server-side — and matches the docker-compose UX users
expect.

What this PR changes
--------------------

- Sources/ContainerResource/Container/ContainerLogOptions.swift (new):
  the ContainerLogOptions struct, Sendable + Codable, with a static
  '.default' equivalent to the original logs(id:) zero-config call.
- Sources/Services/ContainerAPIService/Client/XPC+.swift: two new
  XPCKeys cases ('logSince', 'logTimestamps') for the optional
  parameters.
- Sources/Services/ContainerAPIService/Client/ContainerClient.swift:
  new logs(id:options:) overload. The existing logs(id:) is retained
  as a thin wrapper over .default for source compatibility.
- Sources/Services/ContainerAPIService/Server/Containers/ContainersService.swift:
  matching logs(id:options:) overload; when options.since is provided,
  applies a private 'filterFileHandleSince' that parses ISO-8601
  timestamps from line starts and drops older lines (lines without a
  parseable timestamp pass through unchanged).
- Sources/Services/ContainerAPIService/Server/Containers/ContainersHarness.swift:
  parses the two optional XPC keys, builds ContainerLogOptions, and
  forwards to the new service overload.

Wire compatibility
------------------

XPC calls without the new keys decode as 'sinceRaw.timeIntervalSince1970
== 0' (the harness treats this as 'no since filter') and 'timestamps =
false', so older clients hitting a newer server see unchanged behavior.
Newer clients hitting an older server send the keys; an old harness
will silently drop them and run the original codepath.

Known limitations (intentional, follow-up work)
-----------------------------------------------

- The 'options.timestamps' parameter is plumbed end-to-end but the
  daemon does not currently decorate raw log lines that lack a
  timestamp prefix. Line decoration is a deliberate follow-up; keeping
  the parameter on the API surface today avoids a second wire-format
  break later.
- 'filterFileHandleSince' currently slurps the file into memory then
  returns a Pipe-backed FileHandle. For the typical container log
  size this is fine; for very large logs a streaming line iterator
  would be a worthwhile optimization. Filed as a known-issue for the
  follow-up timestamp-decoration PR.

Verification
------------

Full 'swift build' clean on macOS 26 / Apple silicon (release config,
all targets including downstream consumers of ContainerClient.logs).
@chrisgeo chrisgeo force-pushed the feat/chaos-1322-log-options branch from 77a21ed to 3dac6d5 Compare May 23, 2026 20:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Request]: Add container log retrieval options

1 participant