Fail fast on invalid dedupe TTL strings

[devblac]

Fail fast on invalid dedupe TTL strings

Context

While tweaking dedupe settings, I mistyped a duration (e.g., 10xs), and the runner quietly fell back to a 24h TTL. I only caught it by reading logs and realizing dedupes lasted way longer than intended.

Problem

Runner.NewRunner parses dedupe.ttl but only applies it when parsing succeeds, otherwise silently using the default. Invalid TTL strings are never reported.

Expected behavior

Supplying an invalid TTL string should fail runner construction (or validation) with a clear error. Valid TTL strings should continue to work.

Scope / non-goals

Don’t redesign the dedupe feature or change the default TTL; just surface bad config early.

Acceptance criteria

• Invalid dedupe.ttl strings cause runner setup/validation to return an error.
• Valid TTL strings are still accepted and applied.
• Tests cover both failure and success cases.

Hints

Consider parsing in internal/config/config.go or propagating the error from NewRunner. Tests can live in internal/config and/or internal/engine. Run go test ./internal/config and go test ./internal/engine.