Falcon LogScale 1.265.0 GA (2026-11-03)

Version?Type?Release Date?Availability?End of SupportSecurity UpdatesUpgrades From?Downgrades To?Config. Changes?
1.265.0GA2026-11-03

Cloud

Next LTSNo1.177.01.177.0No

Hide file download links

Show file download links

Bug fixes and updates

Advance Warning

The following items are due to change in a future release.

Deprecation

Items that have been deprecated and may be removed in a future release.

  • The GraphQL field meta has been deprecated and now requires authentication. It will be completely removed in LogScale 1.304. To achieve similar results, use the loginInfo and clusterConfig fields instead.

    To temporarily opt out of the authentication requirement, the feature flag UnauthenticatedMeta can be enabled.

  • The userId parameter for the updateDashboardToken GraphQL mutation has been deprecated and will be removed in version 1.273.

  • The configuration variable USING_EPHEMERAL_DISKS is now slated for deprecation and removal in LogScale version 1.282.

    Because this configuration variable can only be enabled on clusters with bucket storage and there is no use case for disabling it, the option will be deprecated. Instead, LogScale will adopt the correct behavior based on whether bucket storage is configured. When bucket storage is enabled, nodes will be ephemeral; when bucket storage is disabled, nodes will be non-ephemeral.

    Clusters that have configured bucket storage but have not set USING_EPHEMERAL_DISKS will be silently migrated to ephemeral disks.

    Clusters that have configured bucket storage and have explicitly set USING_EPHEMERAL_DISKS to false will crash on boot. Administrators should unset USING_EPHEMERAL_DISKS on such clusters.

    To boot a cluster with bucket storage and include USING_EPHEMERAL_DISKS with it set to false as a temporary measure, set ALLOW_USING_NON_EPHEMERAL_DISKS_WITH_BUCKET_STORAGE to true. This configuration option will also be removed in 1.282, and exists only as an escape hatch.

Behavior Changes

Scripts or environment which make use of these tools should be checked and updated for the new configuration:

  • Configuration

    • LogScale's launch script now enables compact object headers (-XX:+UseCompactObjectHeaders) by default. The flag is part of the default value of the environment variable HUMIO_JVM_PERFORMANCE_OPTS.

      Deployments with their own value for the environment variable HUMIO_JVM_PERFORMANCE_OPTS will not get this flag unless it is added manually. To disable compact object headers, add -XX:-UseCompactObjectHeaders to HUMIO_OPTS.

Upgrades

Changes that may occur or be required during an upgrade.

New features and improvements

  • Security

    • Service user tokens have been added to LogScale. The new GraphQL mutation createServiceUserToken() creates a named token that authenticates as the user and has the same permissions as the user and including an expiration requirement. Creating a service user token does not replace any of the user's other tokens- a user can hold up to 20 unexpired service user tokens at the same time. The limit can be changed with the new dynamic configuration parameter MaxServiceUserTokensPerUser.

      The following rules apply for service tokens:

      • Token names must be unique per user, and follow the same naming convention as other tokens.

      • A service user token cannot be used to create another service user token.

      • A service user token can only be created in the user's own organization, not while proxying into another organization. However, it can be used to proxy into other organizations like a personal user token, if the user has the appropriate permissions to do so.

      • Service user tokens follow the organization's personal user token security policies: enabled, forced expiration, and forced IP filter.

      • Service user tokens follow the permissions of the user. If the user's permissions change, the permissions of the token change accordingly.

      The new field serviceUserTokens on viewer lists the caller's service user tokens. They can be deleted and rotated using the mutations deleteToken() and rotateToken(), and are removed automatically after they expire. They are deleted when the user is deleted. Creating and deleting a service user token is recorded in the audit log, and the creation entry includes the token name. Requests made with a service user token appear in the audit log with the new actor type serviceUserToken.

      The mutations createPersonalUserToken() and createPersonalUserTokenV2(), and the field token on viewer are unchanged and continue working on the user's single existing personal token.

  • GraphQL API

    • The GraphQL mutation setCidSizeForOrganization() has been added; Set the CID size of the organization for a product type.

    • The GraphQL query getCapacityForOrganization() has been added; The capacity of the organization, one entry per product type the organization has.

    • The GraphQL mutation createServiceUserToken() has been added; Create a service user token for the user: a named token that authenticates as the user and inherits the same permissions as the user, like a personal user token. Unlike createPersonalUserTokenV2 it does not replace any of the user's other tokens: a user can have up to 20 unexpired service user tokens by default (dynamic config MaxServiceUserTokensPerUser), each with a unique name. An expiry is required.

    • The GraphQL mutation setCapacityOwnerOrgForOrganization() has been added; Set the organization holding the CID size of the organization for a product type.

    • The GraphQL query formatQuery() has been added; Format a syntactically valid query. The formatting is verified to not change the meaning of the query.

    • A new GraphQL query formatQuery() has been added, which formats the provided query string to a given column width guideline.

  • Ingestion

    • The field name @digesttimestamp is now reserved. Like @id and @ingesttimestamp, a value sent with an event is removed at ingest and the event receives a parser warning, informing the user. Data stored earlier is unchanged. Note that name matches are exact and case-sensitive.

      A new opt-in feature has also been included: LogScale can record @digesttimestamp on each event, holding the time in epoch milliseconds when digest writes the event's batch. This is the closest available approximation of when the event became searchable, and gives a per-event measure of ingest-to-digest delay. This feature is set to off by default.

      To turn the feature on, use the new cluster-wide feature flag WriteDigestTimestamps. When enabled, every repository records the field on digested events. Because the field is stored like any other event field, it appears in search results and can be used in queries. Prior to compression, this adds approximately 17 bytes per event. Turning the feature flag off stops recording for subsequent batches. Already-recorded values are retained.

  • Functions

    • The wildcard() function is now allowed in expressions. This enables the following use cases, which were previously disallowed:

      logscale
      if(wildcard(field=a, pattern="hello*world"), then="yes", else="no")
      logscale
      if(wildcard(pattern="hello*world"), then="yes", else="no")
      logscale
      eval(present = wildcard(field=[x,y], "*foobar*"))
      logscale
      a match { wildcard(pattern="hello*world") => kind := "wild"; ... }

      Note that the wildcard() function without an explicit field argument is still required to occur before the first aggregator.

  • Packages

    • Persisted aggregations in packages can now be used across several views.

      • The same package can be installed in several views that write to the same persisted aggregation repository. Each install gets its own tag, made from the scope, the package, the view, and the name. The destination repository is resolved by name within the view's organization. The user installing the package must have write access to that repository.

      • Queries in a package refer to its persisted aggregations by the alias {scope}/{package}/{name}, or by {scope}/{package}/{view}/{name}. On install, update, and analyze, LogScale rewrites these aliases to the stored tags. On export, it writes them back as aliases.

      • When a package is updated, its persisted aggregations keep their tags. Updates that change fields that cannot normally be edited on a persisted aggregation are rejected.

      • Persisted aggregations served from packages through LARS now run in every view the package is mapped to. Invalid or conflicting aggregations are left out. Aggregations that are no longer served are cleaned up after a grace period.

Fixed in this release

  • Storage

    • An issue has been fixed where work completed on a segment could be undercounted when some data segments took longer to process. Queries processing these segments now open fewer segments at a time, giving other queries a fairer share of the cluster.

    • An issue has been fixed where segments could be orphaned during an organization deletion.

    • An issue has been fixed where corrupt local segment files were not removed if the query that discovered the corruption was canceled at the same time. The corrupt file is now deleted so later queries can download a fresh copy of the segment.

    • An issue has been fixed where sometimes query work would be counted twice when the feature flag BatchHashFilterEvaluations was enabled and a node was assigned to search for a segment that it needed to download, leading to queries not being scheduled as often as they should.

  • Queries

    • An issue has been fixed where queries with blocked subqueries would respond with an incorrect status code. Now, all queries with this issue will respond with the correct 400 status code. Queries started internally now also report the matched blocklist entry instead of a generic submission failure when the block is detected on another node in the cluster.

    • An issue has been fixed where some regular expressions caused regex analysis to get stuck in an infinite loop.

    • An issue has been fixed where live queries restarted from the query state cache could inherit the status and computational cost of the query that wrote the cache. Because the restarted queries then wrote that inherited cost into its own cache entries, the reported cost of live queries could grow with every restart, becoming arbitrarily large. Restarted live queries now only report the cost of their own live work.

    • An issue has been fixed where live queries using the match() function might continue to match against a previous version of the lookup file if the file failed to load only on worker nodes.

    • An issue has been fixed where the reuse of cached query states caused queries to fail if the query was restarted after a Daylight Savings Time (DST) transition.

Known Issues

  • Storage

    • For clusters using secondary storage where the primary storage on some nodes in the cluster may be getting filled (that is, the storage usage on the primary disk is halfway between PRIMARY_STORAGE_PERCENTAGE and PRIMARY_STORAGE_MAX_FILL_PERCENTAGE), those nodes may fail to transfer segments from other nodes. The failure will be indicated by the error java.nio.file.AtomicMoveNotSupportedException with message "Invalid cross-device link".

      This does not corrupt data or cause data loss, but will prevent the cluster from being fully healthy, and could also prevent data from reaching adequate replication.

Improvement

  • GraphQL API

    • The GraphQL datatype ScheduledReport now exposes the field createdInfo, which contains structured creation metadata. Data points include author and timestamp, which is consistent with other asset types such as filter alerts, dashboards, and parsers.

      The existing fields createdBy and creationDate are now deprecated and will be removed in version 1.306. Migration to the createdInfo field is recommended, as it provides richer author information (user, token, and/or system) alongside the creation timestamp.

      Existing scheduled reports are automatically migrated, no action is required.

  • Storage

    • The segment verification job has been improved to make pacing computation more accurate and allow more flexibility with shard assignment to nodes.

    • The bucket storage download code has been adjusted to avoid moving off-heap segment bytes onto the heap during decryption, removing a source of inefficiency.

  • API

    • Oversized keys and values are now automatically truncated to 512 characters with a hash suffix appended for traceability. Previously, queries sent through the external API with extraLogFields keys or values exceeding 512 characters were rejected with the error code HTTP 400. This caused issues when clients, for example LARS dashboards, sent long identifiers in these fields.

  • Fleet Management

    • Testing a Log Collector draft configuration no longer replaces a collector's other applied configurations. The draft under test is now merged with them, matching what will actually apply once published. A collector can also take part in several configuration tests at the same time.