[Reporting] Reporting Job Params should not include timeout and max attempts.

[tsullivan]

Kibana version: 5.0+

Steps to reproduce:

1. Have two Kibana instances
2. KibanaA settings:
   • have xpack.reporting.queue.timeout set to a low value
   • xpack.reporting.queue.pollEnabled set to false
3. KibanaB settings:
   • have queue timeout set to a high value
   • leave the default for pollEnabled.
4. From KibanaA UI, queue a reporting job that is expected to take a long time, but not longer than the KibanaB queue timeout.

Expected behavior:
The report will complete, because it runs on KibanaB and that instance has a high queue timeout set.

Actual:
The report fails, because KibanaA set the timeout as job parameters, and the value is too low.

Any additional context:
The same problem is happening for the max attempts and browser settings in Reporting. They should be referenced from config at execution time, not set at job creation time.

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[tsullivan]

Removing these fields makes it much more complicated for the Management UI to show the values for these settings. I suggest this issue be closed.

[tsullivan]

Removing these fields makes it much more complicated for the Management UI to show the values for these settings. I suggest this issue be closed.

This shouldn't be a blocking issue - the management UI can easily show blank values for jobs that haven't been claimed and having had these fields populated.

This is an issue that can lead to confusion when investigating issues like a job failing before the configured timeout. All of the "runtime" specific fields like timeout and max_attempts should not be saved on the job at the time of creation. It can cause confusion in 2 regards:

• The job can end up running on a different instance that has different values for those settings.
• Even with 1 instance, changing the settings does not affect jobs that are pending.

[tsullivan]

#105508 cleaned this up as part of internal types cleanup. The code uses the actual timeout and max attempts values from the config, and has comments to mention that the timeout and max_attempts are added to the job payload for display purposes only.