Filebeat with Salesforce input and batch

Elastic Stack Beats
1

Can anyone explain why I'm running into this issue? I copied the exact config from the docs here: Salesforce input | Beats

Salesforce input: object.batch.enabled: true fails with "map has no entry for key batch_start_time" after first run - the object.progress_time is never seeded.

Filebeat version: 9.1.1

Environment: Filebeat running in a container (Podman), Salesforce input, JWT bearer auth, object event monitoring method with batching enabled.

Relevant section of config:

event_monitoring_method:
  object:
    enabled: true
    interval: 5m
    batch:
      enabled: true
      initial_interval: 24h
      window: 5m
      max_windows_per_run: 12
    query:
      default: "SELECT FIELDS(STANDARD) FROM LoginEvent WHERE EventDate >= 2026-09-15T17:00:00.000+0000 ORDER BY EventDate DESC"
      value: "SELECT FIELDS(STANDARD) FROM LoginEvent WHERE EventDate > [[ .cursor.object.batch_start_time ]] AND EventDate <= [[ .cursor.object.batch_end_time ]] ORDER BY EventDate DESC"
    cursor:
      field: "EventDate"

Expected behavior: Per the docs ( Salesforce input | Beats ), when batch.enabled: true, the input should seed the first batch window from batch.initial_interval and populate object.progress_time so the value query's [[ .cursor.object.batch_start_time ]] / [[ .cursor.object.batch_end_time ]] templates resolve on every subsequent tick.

Actual behavior: default runs once and successfully collects one file. On the very next tick, the value query fails to render:

{"log.level":"error","@timestamp":"2026-09-15T19:47:33.223Z","log.logger":"input.salesforce",...,"message":"Problem running Object collection: error forming query based on cursor: template: :1:68: executing \"\" at <.cursor.object.batch_start_time>: map has no entry for key \"batch_start_time\""}

This recurs identically even after fully deleting path.data/registry and restarting from a verified-empty state (confirmed via ls -la showing a fresh, just-created registry directory before the second failure). So this isn't stale cursor state — object.progress_time appears to never be initialized on first run when batching is enabled, regardless of registry state.

Reproduction steps:

  1. Configure the object monitoring method as above, with batch.enabled: true.
  2. Start Filebeat with an empty registry.
  3. Observe default runs once, collects data successfully.
  4. Wait for the next interval tick.
  5. Observe the batch_start_time template error on every tick thereafter.

Workaround: Disabling batch and using a plain incremental cursor off object.first_event_time (necessary since the object query is forced ORDER BY EventDate DESC by Salesforce, so the first row per run is the newest) avoids the bug entirely, at the cost of losing windowed catch-up for large backlogs.

2

This is resolved - I upgraded to Filebeat 9.5.0. Elastic is going to update the documentation to note 9.5.0 is the minimum version required for the batching functionality to work.