NVIDIA / NVIDIA/nvcf

feat(request-trace-uploader): persist upload lifecycle state and scope faults

Open
#1,050 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
218
Forks
72
Avg merge
1d 9h
Merged PRs (30d)
417

Description

Why

The initial upload path must evolve into a crash-safe outbox before it can replace the working sidecar for production use. It must also stop treating a broken backend as a stream of broken segments.

Scope

  • Persist source identity, fingerprint, upload identifier, state, and next retry time before relying on remote completion. Write state atomically and synced.
  • Recover in-flight and pending segments after a restart without deleting or silently duplicating a source segment.
  • Acquire an exclusive lock so only one uploader instance processes a given directory at a time.
  • Wait for terminal success before deleting the source. Re-verify the source fingerprint immediately before deletion and refuse to delete a file whose fingerprint changed since submission.
  • Order cleanup as durable success marker, then transport data removal, then source deletion, so a crash mid-cleanup cannot cause a duplicate resubmission.
  • Scope every failure as segment, backend, or unknown. Failures occurring before any network call are segment scope. Backends classify their own remote errors, mapping payload rejection to segment scope and mapping authentication, authorization, quota, connectivity, and server errors to backend scope. Unknown scope is handled as backend scope until correlation resolves it, where a configured number of distinct segments failing with the same signature resolves to backend and one segment failing repeatedly while others succeed resolves to segment.
  • Quarantine only segment-scope faults. Backend-scope faults retain the segment for retry, because the segment is not the defect.
  • Bound quarantine as a configured fraction of the spool in addition to any time-based retention. Evict oldest-first when over budget and count each eviction as data loss.
  • Trip a circuit breaker after a configured number of consecutive quarantines: stop processing new segments and emit a metric rather than continuing to quarantine.
  • Reconcile remote jobs that were started but never confirmed. For backends whose submission is a multi-step remote job, detect a job stuck in a non-terminal state beyond a configured deadline, do not silently resubmit the same segment while an earlier job for it may still be live, and record the stranded job identifier for operator recovery.
  • On shutdown, attempt the active segment that Dynamo has stopped writing, not only segments already closed, within the drain timeout. If it cannot be exported, leave it intact and record that it was not.
  • When a submission outcome cannot be determined, retain the source and its evidence, and neither resubmit nor delete it. Declare resubmit safety per backend rather than assuming it.
  • Move aside state files the uploader cannot parse, or that carry an unrecognized version, together with their segment, and count them. Do not resume an upload from state that cannot be fully interpreted.
  • Verify a configured minimum free space before writing a transport file, and fail the operation rather than write partially.
  • Keep one segment in flight. Do not add configurable policy surface in this increment.
  • Emit lifecycle failures through the uploader's own telemetry without request data, filenames, credentials, request IDs, or remote upload IDs.

Tests

  • Crash and restart recovery before submit, after submit, after journal persistence, after terminal status, and before deletion.
  • Fingerprint mismatch blocks deletion.
  • Segment-scope fault quarantines; backend-scope fault retains and retries.
  • Unknown-scope fault retains, then reclassifies to backend after N distinct segments fail alike, and to segment when one segment fails repeatedly among successes.
  • Quarantine budget eviction and eviction counting.
  • Circuit breaker trips and halts processing.
  • Ambiguous-submit recovery and terminal-success deletion timing tests.
  • Unparseable and unrecognized-version state files are moved aside with their segment rather than deleted or acted upon.
  • Disk-space guard refusal.

Parent: #1004

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the request-trace-uploader implementation and parent issue #1004, then map its persistence, transport, locking, quarantine, and telemetry entry points. Use the listed crash-recovery, fault-scope, quarantine, circuit-breaker, ambiguous-submit, state-file, and disk-space tests as the acceptance checklist. Done means the uploader is crash-safe, avoids unsafe resubmission or deletion, and emits only permitted lifecycle telemetry.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.