JobSchedule.Cron uses a raw String; Every accepts non-positive durations

[sideeffffect]

Severity: low · Category: design / type-safety

Evidence

• src/Models.scala:218 — case Cron(expression: String); :221 — case Every(period: FiniteDuration). Consumed unvalidated at src/internal/JobsCapabilityImpl.scala:66 (JJobSchedule.fromString(expr)).

Problem
The cron expression is the one payload-ish value not given the opaque-type / parse-don't-validate treatment used for every other domain string in the library; a blank or malformed expression (or a zero/negative Every period) is only caught downstream by the sidecar.

Suggested fix
Introduce a CronExpr opaque type (non-empty at minimum, ideally a light 6-field shape check) used by Cron; optionally require Every's period to be strictly positive (matching DaprDuration's non-negativity guard).

[sideeffffect]

Confirmed in the worktree: src/Models.scala:218 is case Cron(expression: String) and :221 case Every(period: FiniteDuration), both unvalidated; the cron string flows straight into JJobSchedule.fromString(expr) at src/internal/JobsCapabilityImpl.scala:66, so a blank/malformed expression only fails at the scheduler. Cron is the one domain string in the library not given the opaque-type treatment that DaprDuration, ETag, DaprPort etc. already use.

CronExpr opaque type in src/optypes/, following the DaprDuration/ETag idiom (smart constructor + value extension), used by Cron(expression: CronExpr):

opaque type CronExpr = String
object CronExpr:
  def apply(s: String): CronExpr =
    val t = s.trim
    require(t.nonEmpty, "CronExpr must not be empty")
    require(
      t.split("\\s+").nn.length == 6,
      s"Dapr cron uses a 6-field (seconds-first) format, got: $s",
    )
    t
  extension (c: CronExpr) def value: String = c

The 6-field count check matches the Scaladoc already on Cron ("Dapr uses a 6-field, seconds-first format") and catches the common mistake of pasting a 5-field Unix crontab. At the call site, change line 66 to JJobSchedule.fromString(expr.value). Keep field-content validation light — leave the per-field range/@every parsing to the scheduler rather than reimplementing it.

Every: mirror DaprDurations guard by requiring a strictly positive period. Since Every is an enum case (no custom constructor), add the check where it is consumed (JobsCapabilityImpl toJavaSchedule), or wrap the period in DaprDuration and reject <= 0 there:

case JobSchedule.Every(period) =>
  require(period > Duration.Zero, s"Every period must be strictly positive, got $period")
  JJobSchedule.fromPeriod(JDuration.ofNanos(period.toNanos))

Both are source-compatible except Cron now takes a CronExpr; existing Cron("...") call sites get a one-token CronExpr("...") wrap.