Splunk timeout parameter vs. manual cancellation for distributed searches

Operational constraint

An API service submits long-running searches to a distributed Splunk deployment and must release search resources without relying on user intervention. Assuming Splunk Enterprise 7.2 or later, the Search Jobs API provides a timeout parameter, while /services/search/jobs/{id}/cancel supports explicit cancellation of a running job.

The design choice is between a server-enforced time box and client-managed cancellation. A timeout provides a simple execution bound from the search head’s perspective. Manual cancellation permits decisions based on application conditions, but the client must track job state and determine when cancellation is appropriate. In a distributed search cluster, timeout and cancellation behavior across search peers requires confirmation for the target release; uniform enforcement and intermediate job states should not be assumed.

Which mechanism should the service use when predictable resource cleanup matters more than adaptive cancellation, and how should it handle a job that remains active after either control is requested?