Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

fix(compaction): batch filename collision causes up to 84% data loss - #358

#358
Merged
xe-nvdk merged 1 commit into
mainBasekick-Labs/arc:mainfrom
fix/compaction-batch-filename-collisionBasekick-Labs/arc:fix/compaction-batch-filename-collisionCopy head branch name to clipboard
Mar 27, 2026
Merged

fix(compaction): batch filename collision causes up to 84% data loss#358
xe-nvdk merged 1 commit into
mainBasekick-Labs/arc:mainfrom
fix/compaction-batch-filename-collisionBasekick-Labs/arc:fix/compaction-batch-filename-collisionCopy head branch name to clipboard

Conversation

@xe-nvdk

@xe-nvdk xe-nvdk commented Mar 27, 2026

Copy link
Copy Markdown
Member

Summary

  • Root cause: When partitions have >30 files, SplitCandidateIntoBatches creates sequential batches of 30. Each batch generated output filenames with second-precision timestamps (YYYYMMDD_HHMMSS), causing all batches to produce identical filenames. Each batch overwrote the previous — only the last batch survived.
  • Impact: Up to 84% data loss on any measurement with >30 files/hour. Triggered by max_buffer_age_ms=500 which produces ~120 files/hour.
  • Fix: Added nanosecond timestamp to compacted filenames for guaranteed uniqueness while preserving YYYYMMDD_HHMMSS prefix for extractNewestFileTime compatibility.

Closes #357

Test plan

  • go build ./cmd/... ./internal/... — clean
  • go test ./internal/compaction/... — pass
  • Deploy to monitoring server and verify data retention across compaction cycles

@gemini-code-assist gemini-code-assist Bot 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.

Code Review

This pull request addresses a critical data loss bug where compaction batches would overwrite each other due to filename collisions caused by second-precision timestamps. The fix introduces nanosecond precision to ensure unique filenames. Feedback suggests refining the filename format by using a single nanosecond-precision timestamp string instead of appending a raw Unix nanosecond value, which improves readability and maintains the existing filename structure.

Comment thread internal/compaction/job.go Outdated
…357)

When partitions had >30 files, SplitCandidateIntoBatches created
sequential batches of 30. Each batch generated output filenames with
second-precision timestamps, causing all batches within the same second
to produce identical filenames. Each batch overwrote the previous,
destroying up to 84% of data.

Fixed by adding UnixNano to compacted filenames for guaranteed uniqueness:
system_20260327_020510_1774577110783053268_compacted.parquet

Also updated extractNewestFileTime to handle both old format
(measurement_YYYYMMDD_HHMMSS_compacted) and new format with nanos
(measurement_YYYYMMDD_HHMMSS_nanos_compacted).

Closes #357

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@xe-nvdk
xe-nvdk force-pushed the fix/compaction-batch-filename-collision branch from becec24 to 0efc610 Compare March 27, 2026 02:24
@xe-nvdk
xe-nvdk merged commit 50cd958 into main Mar 27, 2026
6 checks passed
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.

critical(compaction): batch filename collision causes up to 84% data loss

1 participant

Morty Proxy This is a proxified and sanitized view of the page, visit original site.