Skip to main content

Fire Arrow Server 1.16.1

· 3 min read
Till Gerken
Till Gerken
CTO

Fire Arrow Server 1.16.1 has been released.

  • (feature) $materialize now brings a CarePlan up to the current materialization horizon on every call, instead of only enabling scheduling on the first call
  • (bugfix) CarePlans whose scheduled activities use a versioned reference (.../_history/N) now materialize and complete correctly instead of failing
  • (bugfix) The GraphQL playground at /admin/graphql loads again instead of hanging on a spinner

$materialize Now Materializes Up to the Current Horizon​

CarePlan/$materialize lets a privileged, service-to-service caller turn on server-side scheduling for a CarePlan without creating a Subscription. Before 1.16.1, the operation was designed only to enable scheduling: it added the scheduling opt-in tag, and once that tag was present, repeating the call was intentionally a no-op. This was convenient for switching scheduling back on — for example, for a CarePlan that had been $dematerialized but still had a Subscription.

Callers, however, generally expect a second call to do more than confirm that scheduling is on: they expect $materialize to bring the CarePlan's Tasks up to the current materialization horizon. Because the operation short-circuited once the tag existed, occurrences that entered the rolling horizon after the first call were never materialized by $materialize alone.

Starting with 1.16.1, $materialize materializes the CarePlan up to the current horizon on every call. The first call still adds the opt-in tag, and the operation stays idempotent at the level of individual Tasks — occurrences that are already materialized are never duplicated — but each call now re-evaluates the horizon and creates any Tasks that have newly entered it. A backend that has no Subscription for a CarePlan can therefore call $materialize on a schedule to keep the horizon filled as time advances. No configuration change is required.

Bug Fixes​

Versioned activity references failed to materialize​

A CarePlan activity can point at a specific version of a resource by giving a reference that ends in a /_history/N suffix — for example MedicationRequest/123/_history/2. Before 1.16.1, such references were handled inconsistently across the materialization pipeline: the server fetched the correct version but then failed while assembling the schedule, so the operation errored and no Tasks were created. On the completion side, a plan built from versioned references was never marked complete, because completed activities were compared using their unversioned form and never matched.

Starting with 1.16.1, versioned activity.reference values work end to end: the referenced version is materialized into Tasks, and the CarePlan is marked complete once its activities finish. Unversioned references behave exactly as before, and identifiers that merely contain the text _history (such as MedicationRequest/med_history_1) are treated as ordinary IDs rather than version suffixes.

GraphQL playground hung on a loading spinner​

The interactive GraphQL playground at /admin/graphql failed to load after the browser-based login flow was replaced with a server-side flow in 1.13.0. Instead of the query editor, the page showed a loading spinner that never resolved, and browser fonts used by the editor were blocked by the page's content security policy.

1.16.1 restores the playground: /admin/graphql renders the query editor again for signed-in administrators, and the fonts it needs are no longer blocked. Other parts of the admin web UI are unaffected.