36 posts tagged with "Fire Arrow Server"

Fire Arrow Server 2.1.5 has been released.

• (bugfix) Reading externalized Binary content with $binary-access-read no longer fails with 500 Internal Server Error

Fire Arrow Server 2.1.2 has been released.

• (bugfix) CarePlan activity.reference values that pin a historical resource version (…/_history/N) are now stored and used as sent

Fire Arrow Server 2.1.1 has been released.

• (bugfix) The Azure production image no longer fails to start because of a duplicate binary-storage configuration key

Fire Arrow Server 2.1.0 has been released.

• (security) When the MCP interface is enabled, its endpoints now apply each caller's own authorization rules, and the MCP CDS bridge now enforces an access check (MCP remains off by default)
• (feature) Faster CarePlan Task materialization when the server reaches its database over a network connection
• (bugfix) Attachment reads on historical resource versions no longer break after cleanup or garbage collection
• (bugfix) An invalid CarePlan Task status in configuration now stops the server at startup instead of failing later

Fire Arrow Server 2.0.0 has been released. This is a major release driven by two large bodies of work.

The first is a performance push. Coordinated load tests against production deployments, together with work to optimize real client access patterns — particularly around CarePlan Task materialization — surfaced a number of bottlenecks. This release rewrites the hot paths behind Task materialization and subscription matching and adds bounds and caching throughout.

The second is a systematic review of code quality, security, and scalability. Recent reports of language-model tooling finding previously unknown security issues in old, well-tested code prompted us to run the same kind of review across Fire Arrow Server. Despite already performing manual review and automated quality and security checks on every change, the review turned up a surprising number of issues. We have addressed them here.

Because these two efforts touch a large part of the server — authorization, logging, subscriptions, binary storage, GraphQL, HFQL, the admin proxy, scheduled jobs, and the shipped production configuration — the combined change surface is large enough that we are declaring this a 2.0.0 release. Customers are strongly advised to test 2.0.0 in a staging environment before upgrading production systems.

• (breaking) CarePlan/$materialize now reconciles by default instead of only adding Tasks; pass _reconcile=false for the previous additive behavior
• (breaking) Several defaults now fail safe: binary uploads are restricted to a content-type allow-list, multi-node API-token deployments must set an explicit signing secret, the terminology-upload and subscription-trigger operations are off by default, and the built-in MCP bridges have been removed with MCP disabled by default
• (breaking) Group/$everything, multi-search, and GraphQL now reject over-large or unsigned requests with 413/errors instead of silently truncating
• (breaking) Container health probes now target the liveness endpoint instead of the aggregate health status
• (security) Broad hardening pass across authorization, logging, GraphQL, HFQL, binary storage, and the admin proxy, including PHI redaction in logs, tighter multi-node cache and identity bounds, and injection-hardened query and error paths
• (feature) Large performance improvements to CarePlan Task materialization and subscription matching, validated with production load tests
• (feature) FHIR Binary resources are now offloaded to Azure Blob Storage, with idempotent content-addressed uploads and optional orphan-blob cleanup
• (feature) Safer production image defaults and configurable Azure client timeouts and retries
• (bugfix) CarePlan scheduling edits now preserve in-flight Tasks instead of deleting and recreating them; monthly and yearly schedules no longer drift
• (bugfix) Numerous multi-node and large-dataset correctness and reliability fixes across subscriptions, scheduled jobs, licensing, and uploads
• (maintenance) Broad internal code-quality pass and Fire Arrow database migrations that apply automatically on startup

Fire Arrow Server 1.16.2 has been released.

• (bugfix) Polling-only CarePlan-event subscriptions no longer stall server startup when Azure Queue is not enabled
• (feature) New fire-arrow.search.reindex-on-startup-when-index-missing setting rebuilds the search index on cold start for deployments using ephemeral storage

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

Fire Arrow Server 1.16.0 has been released.

• (feature) CarePlans now carry a materialized-at-version marker, so a client can tell when the server has finished creating Tasks for its latest update without making a synchronous call
• (bugfix) A scheduled activity's own Timing.repeat.duration now sets how long the resulting Task stays actionable, instead of always using the server-configured validity period

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

Fire Arrow Server 1.14.0 has been released.

• (breaking) The web UI now signs in through a server-side confidential OAuth client; every login profile must be given a client secret and have its identity provider redirect URI updated before upgrading, or the server will not start
• (feature) A new $drop-privilege operation lets a privileged caller mint a short-lived token scoped down to a single identity, never granting more access than the caller already has