Skip to main content

Fire Arrow Server 1.15.0

· 4 min read
Till Gerken
Till Gerken
CTO

Fire Arrow Server 1.15.0 has been released.

  • (feature) On the synchronous activation path, past-due care plan Tasks are created directly in ready status instead of being created as requested and immediately transitioned
  • (feature) Synchronous CarePlan/$subscribe-due-events results are returned in due-time order, so the first entry is the most urgent actionable Task
  • (bugfix) The immediate post-activation due-task transition now respects auto-transition-to-ready; previously it ran even when that setting was disabled
  • (maintenance) Platform and dependency updates, including a jackson-databind security fix in the license tooling

Past-Due Tasks Start in ready on Synchronous Activation​

When a client activates due-event delivery for a CarePlan on the synchronous path (CarePlan/$subscribe-due-events with _synchronous=true), the server materializes Task resources for the plan's scheduled activities. For occurrences whose due time had already passed at that moment, the server used to create the Task in requested and then, in a second step, query it back and update it to ready. During the short window between those two steps a past-due Task was visible as requested even though it was already actionable, and the extra query-and-update cycle added avoidable database and subscription-delivery work at activation time.

Starting with 1.15.0, on the synchronous activation path the server creates such past-due Tasks directly in the configured due-status (default ready), skipping the follow-up query and update. A Task whose due time is in the past is ready the moment it is created, and the synchronous $subscribe-due-events response reflects that immediately.

This applies only when a Task would auto-transition anyway: the CarePlan has a resolved timezone (local-time-only Tasks are never auto-transitioned), auto-transition-to-ready is enabled, and the occurrence's due time is at or before the current time. Future-due occurrences are still created in initial-status (requested) and moved to ready by the scheduled due-task sweeper when their time arrives. Client subscriptions still fire exactly once per past-due Task — a Task created as ready matches the Task?status=ready&based-on=CarePlan/{id} subscription criteria on creation, so downstream consumers receive the same single notification as before. No configuration change is required.

Synchronous Due-Event Results Are Ordered by Due Time​

CarePlan/$subscribe-due-events with _synchronous=true returns the materialized Tasks in the response. Before 1.15.0 those Tasks came back in an undefined order, so a client that wanted to act on the most urgent Task first had to sort the returned bundle itself.

Starting with 1.15.0, the synchronous response is sorted in ascending due-time order (based on each Task's restriction.period.start). The first entry is always the most urgent actionable Task. Only the ordering of the response changes; which Tasks are returned is unchanged, and no configuration change is required.

Bug Fixes​

Immediate due-task transition ignored auto-transition-to-ready​

On the synchronous activation path, immediately after materialization the server runs a one-time pass that moves any already-due Tasks for the CarePlan from requested to ready. Before 1.15.0 this pass ran even when auto-transition-to-ready was set to false — the setting that is meant to disable automatic requested → ready transitions. Deployments that had deliberately turned auto-transition off therefore still saw past-due Tasks flipped to ready once, right after activation, which was inconsistent with the scheduled due-task sweeper (which already honored the setting).

1.15.0 gates this immediate transition on the same auto-transition-to-ready flag. With the flag enabled (the default), behavior is unchanged. With the flag disabled, past-due Tasks now stay in initial-status (requested) until a client acts on them, matching the scheduled sweeper and the documented meaning of the setting. If your deployment sets auto-transition-to-ready: false and relied on this immediate flip to ready, you must now advance those Tasks yourself, since the server no longer transitions them automatically.

Dependency Upgrades​

1.15.0 rolls up routine platform and dependency updates. The embedded HAPI FHIR platform moves from 8.10.0 to 8.10.1; because this is a patch-level update, no HAPI schema migration is required. It is accompanied by patch updates to Spring Boot, the PostgreSQL JDBC driver, Logback, and Kotlin. The license tooling picks up a jackson-databind security update; the server runtime and administration UI are not affected by that particular fix. The administration UI also receives routine patch updates to Next.js and React. No configuration change is required to upgrade.