You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-Xmacro-settings:{circe,cats,avro}Derivation.timeout=30 had been in build.sbt since the
kindlings 0.3.0 pin and did nothing. kindlings' DerivationTimeout parses the value with
and the call site is flatMap(parse).getOrElse(Default) with Default = 5 SECONDS. A bare
integer has no unit, never matches, and is discarded — no warning, no error. Every derivation
had been running on 5s rather than 30s, so the recurring "derivation timed out" CI flake the
setting was added for was never actually mitigated.
Fixed in #102 by spelling every value with its unit (=30s build-wide, =120s for mdoc
fences), verified by canary:
-Xmacro-settings:avroDerivation.timeout=1ms EXIT=1 Macro … timed out after 1ms
-Xmacro-settings:avroDerivation.timeout=1 EXIT=0 (bare integer: discarded)
-Xmacro-settings:avroDerivation.timeout=30s EXIT=0
Why this needs a guard
Nothing in the build fails when the key goes dead. The failure mode is silent by construction:
a wrong spelling, a renamed namespace after a kindlings bump, or a dropped setting all look
identical to "everything is fine" until a loaded runner starts flaking again. The build comment
added in #102 documents the canary procedure, but it is a manual step someone has to remember.
Suggested shape
A negative fixture cannot live in the main build — scalacOptions are build-wide, so setting 1ms anywhere would break every module. Options, roughly in order of cost:
An sbt-scripted test, or a tiny throwaway sub-project outside the root aggregate, that
compiles one derivation under avroDerivation.timeout=1ms and asserts the compile FAILS with timed out after 1ms. Run it in quality.yml rather than on every PR.
The same class of silent-no-op applies to the mdoc fence channel, which already has its own
documented canary (mdocExtraArguments vs mdoc.properties) — worth covering in the same guard.
What happened
-Xmacro-settings:{circe,cats,avro}Derivation.timeout=30had been inbuild.sbtsince thekindlings 0.3.0 pin and did nothing. kindlings'
DerivationTimeoutparses the value withand the call site is
flatMap(parse).getOrElse(Default)withDefault = 5 SECONDS. A bareinteger has no unit, never matches, and is discarded — no warning, no error. Every derivation
had been running on 5s rather than 30s, so the recurring "derivation timed out" CI flake the
setting was added for was never actually mitigated.
Fixed in #102 by spelling every value with its unit (
=30sbuild-wide,=120sfor mdocfences), verified by canary:
Why this needs a guard
Nothing in the build fails when the key goes dead. The failure mode is silent by construction:
a wrong spelling, a renamed namespace after a kindlings bump, or a dropped setting all look
identical to "everything is fine" until a loaded runner starts flaking again. The build comment
added in #102 documents the canary procedure, but it is a manual step someone has to remember.
Suggested shape
A negative fixture cannot live in the main build —
scalacOptionsare build-wide, so setting1msanywhere would break every module. Options, roughly in order of cost:sbt-scriptedtest, or a tiny throwaway sub-project outside the root aggregate, thatcompiles one derivation under
avroDerivation.timeout=1msand asserts the compile FAILS withtimed out after 1ms. Run it inquality.ymlrather than on every PR.scalacdirectly againstavroIntegration/Test/fullClasspathwiththe
1msflag and greps the error — no build wiring at all, which is how the build(deps): hearth 0.4.2 / kindlings 0.3.2 — break the 23-element tuple ceiling on.fields#102 canary wasactually run.
Either way the assertion is the same: the key is live iff
1msmakes a derivation fail.Related
.fields#102 (the fix and the measurements)documented canary (
mdocExtraArgumentsvsmdoc.properties) — worth covering in the same guard.