Skip to content

feat(push): end-to-end ingest correlation id — print it on submit (backend#1028 item 3)#245

Open
LukasWodka wants to merge 1 commit into
developfrom
feat/1028-ingest-correlation-id
Open

feat(push): end-to-end ingest correlation id — print it on submit (backend#1028 item 3)#245
LukasWodka wants to merge 1 commit into
developfrom
feat/1028-ingest-correlation-id

Conversation

@LukasWodka

@LukasWodka LukasWodka commented Jul 12, 2026

Copy link
Copy Markdown
Contributor

Summary

Prints the run's correlation id on tracebloc dataset push (backend#1028 item 3). The idempotency key the CLI already generates and sends is becoming the end-to-end ingest correlation id — jobs-manager derives the Job name from it, labels every spawned resource with it, and stamps it into the ingestor container as TRACEBLOC_INGEST_CORRELATION_ID; the ingestor logs it and ships it in the backend registration payload. The CLI was the only layer that never showed the key, so the customer had no copy of the one string that threads all layers together. One Hintf line on every submit path (fresh and replay) fixes that. No wire change.

Related

Ref tracebloc/backend#1028 (item 3). Sibling PRs: tracebloc/client-runtime#176 (stamps the Job env) and tracebloc/data-ingestors#368 (ingestor honours it).

The cross-repo contract

  • One id: the CLI's existing per-invocation idempotency key (32-char crypto/rand hex from BuildRequest, or the customer's --idempotency-key; jobs-manager caps it at 64 chars).
  • This PR: print Correlation id: <key> after the submit announcement — on replay too, since a replayed run is exactly when you reach for the id to find the already-running Job.
  • Downstream: client-runtime#176 sets TRACEBLOC_INGEST_CORRELATION_ID=<key> on the Job; data-ingestors#368 validates it (^[A-Za-z0-9._-]{1,64}$, fallback = today's behaviour), logs Correlation id: <id> (ingestor_id: <uuid>), and lands meta_data.correlation_id on the backend dataset row.
  • Merge order: any. The env is optional at every layer; this print is standalone and true today (the label/Job-name derivation already exists in deployed jobs-managers).

Test plan

  • New TestRun_PrintsCorrelationId_GeneratedKey (auto-generated key echoed) and TestRun_PrintsCorrelationId_OverrideAndReplay (--idempotency-key override echoed verbatim on the replay path).
  • make ci (vet + go test -race -cover ./... + lint + fmt-check + schema-check) → all green.

Adjacency

Open PR #235 also touches internal/submit/submit_test.go (lint/dead-export cleanup) — my additions are new test funcs, worst case a trivial rebase. #232 touches internal/submit/summary.go only; this PR deliberately does not change the summary banner or its parser.

Checklist

  • Tests added / updated and passing locally
  • Docs updated if behavior or config changed (help text unchanged — output-only addition)
  • No secrets / credentials in the diff

🤖 Generated with Claude Code


Note

Low Risk
Output-only hint line in the submit flow; no changes to auth, request payloads, or cluster behavior.

Overview
After a successful submit, tracebloc dataset push now prints Correlation id: <idempotency key> on every path (fresh submit and replay), right after the existing success/replay message. The value is the same idempotency key already sent to jobs-manager—no API or wire changes.

Tests assert the line appears for an auto-generated key and for an explicit --idempotency-key on replay.

Reviewed by Cursor Bugbot for commit 7ab32a8. Bugbot is set up for automated code reviews on this repo. Configure here.

…em 3)

The idempotency key the CLI already sends is becoming the end-to-end
ingest correlation id: jobs-manager derives the Job name from it, labels
every spawned resource with it, and (client-runtime) stamps it into the
ingestor container as TRACEBLOC_INGEST_CORRELATION_ID, where the
ingestor (data-ingestors) logs it and carries it into the backend
registration payload.

The CLI was the only layer that never showed the key, so the customer
had no copy of the one string that threads all layers together. Print
it as a hint line on every submit path — fresh and replay (a replayed
run is exactly when you reach for the id to find the already-running
Job).

No wire change: the key was already in the POST body.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@LukasWodka LukasWodka requested a review from aptracebloc July 12, 2026 11:19
@LukasWodka

Copy link
Copy Markdown
Contributor Author

👋 Heads-up — Code review queue is at 51 / 30

Above the WIP limit. The team convention is to review existing PRs before opening new work.

Open PRs currently in Code review (oldest first):

Pull from review before opening new work. (This is a nudge from the kanban WIP check, not a block.)

@aptracebloc aptracebloc left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

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.

2 participants