Normalize since/date-range parsing across substreams logs commands - #222
Open
maoueh wants to merge 1 commit into
Open
Normalize since/date-range parsing across substreams logs commands#222maoueh wants to merge 1 commit into
maoueh wants to merge 1 commit into
Conversation
logs connection and logs connections handled time ranges through two unrelated interfaces with incompatible parsers, so a value copied between them broke — most visibly --since 2d on connections, which Go's native time.Duration parser rejects (no d unit). logs connection now takes --since/--date-range flags instead of a positional date-range argument, matching logs connections. Both share one relative-duration/date-range parser now, and all three commands (connection, connections, reexec) gained a 1w shortcut (d == 24h, w == 7d == 168h, fixed-length to avoid calendar ambiguity).
Contributor
🔍 Vulnerabilities of
|
| digest | sha256:76f1bc5db9dda1a40ef5dd1adba7071870570f998662e3242389a5b5164a069a |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 160 MB |
| packages | 509 |
📦 Base Image ubuntu:24.04
| also known as |
|
| digest | sha256:1e0a86e57d247923571b75e0aaf48a1449cf8c543d51fb3e07a4a7d7bfa79316 |
| vulnerabilities |   |
sduchesneau
reviewed
Aug 25, 2026
| cmd.Flags().String("backend", "gcp", "Log backend to use (currently only 'gcp' supported)") | ||
| cmd.Flags().Duration("since", time.Duration(0), "Look back duration (e.g., '1h', '30m', '2d'). Mutually exclusive with --date-range") | ||
| cmd.Flags().String("date-range", "", "Date range in format '<start>[/<end>]'. End defaults to now. Mutually exclusive with --since") | ||
| cmd.Flags().String("since", "", sinceFlagHelp) |
Contributor
There was a problem hiding this comment.
That's weird with those two flags possibly doing the same thing..
functionally identical:
--since=1h
--date-range=1h
maybe we should have just --since= and --until= ?
like:
--since=24h and --until=1h
--since=2026-05-21T10:23:12Z and --until=2026-05-22T10:23:12Z
We could also accept --since=24h and --until=+2h30m
So there wouldn't be overlap between the function of both flags.
Either you use just --since with a duration (most common case for "last x hours")
Either you use both with durations --since=48h --until=24h (sous-entendu: "ago")
Either you use timestamps
Either you use timestamp for since, and use an until that is relative to the since (with + prefix)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
firecore tools substreams logs connection(singular) andlogs connections(plural) handled time ranges through two unrelated interfaces — a positional[<date-range>]argument on one, a--since/--date-rangeflag pair on the other — with incompatible parsers underneath. Copying a value between the two broke, most visibly--since 2donconnections, which Go's nativetime.Durationflag parser rejects outright (nodunit).logs connectionnow takes--since/--date-rangeflags instead of a positional date-range argument, matchinglogs connections.--sinceis a relative duration (30m,2h,1d,1w,"1 day ago", …),--date-rangeaccepts slash, colon, or bare-timestamp forms.connection,connections,reexec) gained a1wshortcut. Units are fixed-length to dodge calendar ambiguity:d== 24h,w== 7d == 168h.logs reexeckeeps its positional date-range argument (out of scope here) but shares the same underlying relative-duration parser, so1wworks there too.Net effect: a since/date-range value copied from a
logs connectionslisting straight intologs connection <trace-id> --since .../--date-range ...now works unchanged — the workflow this was built around.Trade-offs
logs connection's date-range is no longer a positional argument — this is a breaking CLI change for that command, done deliberately to normalize withlogs connectionsrather than keep two shapes.--date-range "2024-01-15T10:00:00Z/") — a bare timestamp without any separator already means the same thing.Test plan
go build ./...go test ./cmd/...logs connection <trace-id> --since 1w,logs connections --since garbage(clean error),--date-rangewith colon separator viago run ./cmd/firecore tools substreams logs ...