[Reporting] Fix timestamp override for ES|QL CSV scheduled reports with relative time ranges

[doakalexi]

Resolves #245281

Summary

This PR updates the code to generate ES|QL csv reports to use forceNow for relative time ranges. To do this we added a new locator function to get the timeFieldName from the job params bc the ES|QL time range filters don't have the meta field populated.

Checklist

Check the PR satisfies following conditions.

• Unit or functional tests were updated or added to match the most common scenarios

To verify

1. Create a data view on .kibana-event-log*
2. Use the query below in dev tools to create a scheduled report with a hardcoded relative time range (You can adjust the timerange in the job params to what you want when you're testing)
3. Verify that the eventual CSV report has data in the correct time range

Query

This scheduled report will run every minute 🙂

POST kbn:/internal/reporting/schedule/csv_v2
{
"schedule": {
  "rrule": {
    "freq": 3,
    "interval": 1,
    "byhour": [
      0,
      1,
      2,
      3,
      4,
      5,
      6,
      7,
      8,
      9,
      10,
      11,
      12,
      13,
      14,
      15,
      16,
      17,
      18,
      19,
      20,
      21,
      22,
      23
    ],
    "byminute": [
      0,
      1,
      2,
      3,
      4,
      5,
      6,
      7,
      8,
      9,
      10,
      11,
      12,
      13,
      14,
      15,
      16,
      17,
      19,
      19,
      20,
      21,
      22,
      23,
      24,
      25,
      26,
      27,
      28,
      29,
      30,
      31,
      32,
      33,
      34,
      35,
      36,
      37,
      38,
      39,
      40,
      41,
      42,
      43,
      44,
      45,
      46,
      47,
      48,
      49,
      50,
      51,
      52,
      53,
      54,
      55,
      56,
      57,
      58,
      59
    ]
  }
},
"jobParams": "(browserTimezone:America/Los_Angeles,isEsqlMode:!t,locatorParams:!((id:DISCOVER_APP_LOCATOR,params:(columns:!(),dataViewSpec:(allowHidden:!f,allowNoIndex:!f,fieldFormats:(),id:'1a05eb41b8d4c4075bf8e71e472bc9855314219a15ddb77af59342159e67beb2',managed:!f,name:'.kibana-event-log*',runtimeFieldMap:(),sourceFilters:!(),timeFieldName:'@timestamp',title:'.kibana-event-log*',type:esql),filters:!(),hideChart:!t,interval:auto,query:(esql:'FROM .kibana-event-log*'),refreshInterval:(pause:!t,value:60000),sort:!(),tab:(id:'203820a6-4f09-4b15-93c4-5d70924f3e52',label:Untitled),timeRange:(from:'2025-12-31T00:00:00.000Z',to:'2026-12-07T00:00:00.000Z')))),objectType:search,title:'Untitled Discover session',version:'9.4.0')"
}

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[pmuellr]

LGTM

[pmuellr]

Can we change this to return params.dataViewSpec?.timeFieldName; ?

[doakalexi]

Yeah! Updated in this commit, ed06b25

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 6afa934

Failed CI Steps

• FTR Configs #4

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/generate-csv	29	31	+2
discover	159	161	+2
total			+4

Unknown metric groups

API count

id	before	after	diff
@kbn/generate-csv	29	31	+2
discover	202	204	+2
total			+4

History

• 💛 Build #379681 was flaky 35dd7f4
• 💔 Build #379219 failed 50e088a
• 💔 Build #378814 failed 577c414

[davismcphee]

Code-only review, Data Discovery changes LGTM, although it wasn't clear to me how to test from the PR or linked issue. The PR mentions relative time ranges, but the example request seems to use an absolute time range.

[davismcphee]

Suggested change

	if (params.dataViewSpec && params.dataViewSpec.timeFieldName) {
	return params.dataViewSpec?.timeFieldName;
	}
	return params.dataViewSpec?.timeFieldName;

I think the original suggestion was probably to drop the if statement entirely in favour of optional chaining, which makes sense because shouldn't need both.

On a separate note, I have some reservations about relying on dataViewSpec for ES|QL reports, but I see we already do it for other properties and don't currently have an alternative to suggest. Just feels like it shouldn't be necessary for ES|QL in general.

[doakalexi]

Oh okay, that's my bad. I misunderstood Patrick's comment

Sorry for not being clear, sometimes when they user specifies a relative time range it get's saved as an absolute time range. We received an SDH about it and I can replicate this in 8.19, but in main rn I can't get it to save as the absolute time range. In the verification steps I provide a scheduled report that forces it to be an absolute time range, so you can verify that the code overrides the time range.

[davismcphee]

No worries, and thanks for explaining! I understand better now and think we're good to merge this.

FWIW the SDH bug sounds like this one: #223171. We merged a fix for it in #223249 (8.19 backport in #223346), but it was overwritten by a separate backport and missed the 8.19 release. We then merged a separate fix for it to 8.19.7 in #241931. So users who encounter it in earlier versions of 8.19 will need to upgrade to 8.19.7+ to fix it.

[doakalexi]

Oh nice, thanks!

[kibanamachine]

Starting backport for target branches: 8.19, 9.1, 9.2, 9.3

https://github.com/elastic/kibana/actions/runs/20999463337

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.19
✅	9.1
✅	9.2
✅	9.3

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation