Back to Blog

RIDDL 2.3.1 Released

RIDDL 2.3.1 is now available.

release riddl compiler

RIDDL 2.3.1 is now available. This release of the RIDDL compiler and language tooling includes the following changes:

What’s New

What’s New

A single-fix release: a terminal sink is no longer asked to invent an entity to dispatch to.

Bug Fixes

  • handler-streamlet-foreign-message no longer fires on a sink that does real work. The rule asked a sink whose handler contains no tell why it handles messages without dispatching to an entity. That is a fair question of an intake sink — one placed to receive from outside and hand the work to an entity — and the wrong question of a terminal one, which is a boundary into something that is not an entity at all. The rule had already been narrowed twice for exactly that reason, once for the routing shapes (split, merge, flow) and once for repository and projector, each time by exempting one more processor kind.

    A display screen was the third such boundary: a kitchen display that logs a ticket and renders it has no entity to tell, and telling the ticket back to the entity that yielded it is a round trip no generator should emit.

    Rather than exempt a fourth kind, the rule now asks the question it can answer honestly: has the sink said what it does with what it receives? A clause containing executable work — a tell, a log, a put to an output, a write, a refusal, a code block — has said, whatever the destination. A clause holding only prose (do "…") or nothing has not, and that is the only case still reported.

    Why this generalizes: “a sink dispatches into entities” was never a fact about sinks, it was a fact about one use of them, so every new kind of boundary — storage, a projection, a screen — arrived as a false positive in a model that was already correct.

Changed diagnostics

  • The message for handler-streamlet-foreign-message now reads “handles messages but does not say what it does with them”, with a suggestion naming every way a sink can say so. The previous wording named tell and entities specifically, which the narrowed rule no longer asks about — a true diagnostic with a false explanation.

    The rule id is unchanged. Tooling that keys on RuleId values is unaffected; anything matching on the message text of this one rule needs updating. The rule’s severity (Completeness) and gating (--show-completeness-warnings) are also unchanged.

Internal

  • The enumeration of “executable work” now exists once (ValidationPass.isExecutableStatement) rather than in both the sink check and classifyHandlers, so the two cannot drift apart as statement kinds are added. It is an exhaustive match with no wildcard, so a new statement kind fails the build rather than silently counting as neither work nor prose.
  • TerminalSinkDoesWorkTest pins all four cases, including the prose-only negative control that must still report.