Repository navigation
fix(azure): recognize zone-less timestamps in CD log lines - #2287
Merged
Merged
Conversation
parseCDLogLine (added by #2244 to fix #2079) only recognized the pulumi wrapper's full RFC3339Nano timestamps. Azure's logStreamEndpoint also injects its own "Connecting to container" banner line, timestamped with the same layout but no trailing zone designator (e.g. "2026-09-16T11:25:39.178105928" instead of "...928Z"). RFC3339Nano parsing rejects that outright, so the line fell back to the raw-line + time.Now() path, reproducing the double-timestamp bug for that one line (#2275). Add a second timestamp layout without a zone designator, parsed as UTC, to parseCDLogLine's existing fallback loop. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XDEqMD6nq4tfs9yDe23iWM
Contributor
|
Warning Review limit reachedYour organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Next included review available in 4 minutes. View limit detailsLimit details: You’ve used all 3 included reviews currently available. Your 45 included PR review attempts over the past 7 days set your current allowance at 3 reviews per hour. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (2)
Comment |
lionello
approved these changes
Oct 3, 2026
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
Fixes #2275. Follow-up to #2244 (which fixed #2079).
parseCDLogLinestrips the CD job's embedded engine timestamp out of each log line so it isn't shown twice (once as the CLI's own read-time column, once baked into the message). It only recognized fullRFC3339Nanotimestamps (2026-04-28T23:43:03.965786510Z - worker deleting (0s)), which is what the pulumi wrapper's own stdout lines use.Azure's
logStreamEndpoint(used for live-follow CD logs,job.go'sstreamJobExecutionLogs) also injects its own informational banner line when it connects, e.g.:That timestamp uses the same layout but without a trailing zone designator (no
Z/offset), whichtime.Parse(time.RFC3339Nano, ...)rejects outright. So this one line fell through to the pre-#2244 fallback (raw line asMessage,time.Now()asTimestamp), reproducing the exact double-timestamp symptom #2079/#2244 were meant to fix.Fix
Add a second candidate layout (
"2006-01-02T15:04:05.999999999", no zone) toparseCDLogLine's existing parse loop, parsed as UTC. RFC3339Nano is still tried first, so CD-job stdout lines are unaffected.Test plan
TestParseCDLogLinecovering a zone-less timestamp with fractional seconds (matching the reported line) and one with seconds-only precision (matching Azure's documented connect-banner format)go test -short ./pkg/cli/client/byoc/azure/...passesgolangci-lint run ./pkg/cli/client/byoc/azure/...reports 0 issuesgo build ./...succeeds🤖 Generated with Claude Code