Duration parsing accepts zero values, data expires immediately

[umag]

Description

In src/domain/data/data_lifecycle_service.ts (lines 337-341), parseDuration() accepts zero values like "0h", "0d", "0w" which produce 0 milliseconds. The LifetimeSchema regex /^\d+(mo|y|h|m|d|w)$/ also matches these. Data configured with a zero lifetime expires immediately on creation.

Steps to Reproduce

1. Create data with lifetime "0h" — passes schema validation
2. The data expires immediately (expiration = creation time + 0ms)
3. GC deletes the data on next scan

Expected Behavior

Zero durations should be rejected by the schema validation. The regex should require at least 1 for the numeric part.

Actual Behavior

"0h", "0m", "0d", "0w", "0mo", "0y" all pass validation and produce 0ms duration.

Summary

This affects duration parsing in the data lifecycle service. The fix would involve changing the regex to /^[1-9]\d*(mo|y|h|m|d|w)$/ or adding a post-parse check that the numeric value is > 0.

[stack72]

Implementation Plan: Treat zero-duration lifetime as workflow lifetime

Instead of rejecting zero-duration values, we'll treat them as "workflow" lifetime — meaning the data is only available for the lifetime of the workflow run.

For the GarbageCollectionSchema, zero-duration strings will be rejected (the numeric 0 case is already rejected by .positive()).

Changes

1. Add normalizeLifetime() helper — src/domain/data/data_metadata.ts

Add a function that converts zero-duration strings ("0h", "0d", "0w", "0m", "0mo", "0y", "00d", etc.) to "workflow":

export function normalizeLifetime(lifetime: Lifetime): Lifetime {
  if (typeof lifetime === "string") {
    const match = lifetime.match(/^(\d+)(mo|y|h|m|d|w)$/);
    if (match && parseInt(match[1], 10) === 0) {
      return "workflow";
    }
  }
  return lifetime;
}

2. Normalize in Data.create() and Data.fromData() — src/domain/data/data.ts

Call normalizeLifetime() on the lifetime value before passing it to DataMetadataSchema.parse():

• In Data.create(): normalize props.lifetime before validation
• In Data.fromData(): normalize data.lifetime before validation (handles existing on-disk data with "0h")

3. Reject zero-duration in GarbageCollectionSchema — src/domain/data/data_metadata.ts

Update the GC regex from /^\d+(mo|y|h|m|d|w)$/ to /^[1-9]\d*(mo|y|h|m|d|w)$/ so that "0h", "0d" etc. are rejected for garbage collection.

4. Add tests

• src/domain/data/data_lifecycle_service_test.ts: Test that calculateExpiration with "0h" returns null (same as "workflow"), test Data.create() with "0h" produces lifetime: "workflow"
• src/domain/data/data_metadata_test.ts: Unit tests for normalizeLifetime() covering all zero variants, non-zero pass-through, and special values

Files to modify

File	Change
src/domain/data/data_metadata.ts	Add normalizeLifetime(), update GC regex
src/domain/data/data.ts	Call normalizeLifetime() in create() and fromData()
src/domain/data/data_lifecycle_service_test.ts	Add zero-duration lifetime tests
src/domain/data/data_metadata_test.ts	Add normalizeLifetime unit tests

[stack72]

@adamhjk I'd love your eyes on this plan please!

[adamhjk]

this makes sense. if I have a workflow lifetime and a gc of 1, what do we expect to happen?