So I spun up a new Splunk instance in Podman (completely clean) and ingested the same file and the behaviourt is the same with no line breaking! This is with UTF8 encoding and CRLF or LF endings. So I went into the UI and created a sourcetype for it:   [netlogon] DATETIME_CONFIG = LINE_BREAKER = ([\r\n]+) NO_BINARY_CHECK = true SHOULD_LINEMERGE = false category = Custom pulldown_type = 1   Now working on 9.2.0.1 but not on 9.1.2

You haven't provided description/sample of your data so we don't know - for example - how many events you can have per each contextId but I suppose you're simply looking for something like index="log-3258-prod-c" | stats values(user_name) as user_name  values(Flow) as Flow [... more aggregations here ...] by contextId If you want to list all fields, you can simply shorthand the stats to | stats values(*) as * by contextId

Firstly, if your subsearch uses the same source index as the outer search, it's more often than not that the search can be written without using the subsearch. Secondly, the subsearches have their limitations (for execution time and number of returned results). Their most confusing and annoying "feature" however is that if the subsearch hits such limit, it gets silently finalized and you're only getting partial (possibly empty) results from the subsearch _with no warning about that whatsoever_. So if your subsearch run on its own produces proper results and your "outer search" with the results from the subsearch manually copy-pasted produces proper results as well it's highly probable that this is the issue you're hitting. Check your job log to see what your main search is rendered into in the end (after the subsearch is run). (Of course @ITWhisperer 's point of field extraction is still valid).

@ITWhisperer  Changed to match format as detailed... index=blah [search index=blah "BAD_REQUEST" | rex "(?i) requestId (?P<search>[^:]+)" | table search | dedup search] ...but new format ONLY returned rows containing 92d246dd-7aac-41f7-a398-27586062e4fa [first row] and no other rows.  I removed 'dedup' but that did not help How can I include all returned items from inner search as input to outer [main] search?  

This is the full error output,   Migrating to: VERSION=9.2.0.1 BUILD=d8ae995bf219 PRODUCT=splunk PLATFORM=Linux-x86_64 ********** BEGIN PREVIEW OF CONFIGURATION FILE MIGRATION ********** Traceback (most recent call last): File "/opt/splunk/lib/python3.7/site-packages/splunk/clilib/cli.py", line 39, in <module> from splunk.rcUtils import makeRestCall, CliArgError, NoEndpointError, InvalidStatusCodeError File "/opt/splunk/lib/python3.7/site-packages/splunk/rcUtils.py", line 17, in <module> from splunk.search import dispatch, getJob, listJobs File "/opt/splunk/lib/python3.7/site-packages/splunk/search/__init__.py", line 17, in <module> from splunk.rest.splunk_web_requests import is_v2_search_enabled File "/opt/splunk/lib/python3.7/site-packages/splunk/rest/splunk_web_requests/__init__.py", line 1, in <module> import cherrypy File "/opt/splunk/lib/python3.7/site-packages/cherrypy/__init__.py", line 76, in <module> from . import _cprequest, _cpserver, _cptree, _cplogging, _cpconfig File "/opt/splunk/lib/python3.7/site-packages/cherrypy/_cpserver.py", line 6, in <module> from cherrypy.process.servers import ServerAdapter File "/opt/splunk/lib/python3.7/site-packages/cherrypy/process/__init__.py", line 13, in <module> from .wspbus import bus File "/opt/splunk/lib/python3.7/site-packages/cherrypy/process/wspbus.py", line 66, in <module> import ctypes File "/opt/splunk/lib/python3.7/ctypes/__init__.py", line 551, in <module> _reset_cache() File "/opt/splunk/lib/python3.7/ctypes/__init__.py", line 273, in _reset_cache CFUNCTYPE(c_int)(lambda: None) MemoryError Error running pre-start tasks

Hi If I understand correctly your issue is that you have some data with online access after you want that this has deleted from splunk and archived or just deleted? You have/must have to define this based on retention time as say e.g. in legislation?  There is (at least) one excellent .conf presentation how splunk handles data inside it. You should read this https://conf.splunk.com/files/2017/slides/splunk-data-life-cycle-determining-when-and-where-to-roll-data.pdf. Even it's already kept couple of years ago, it's still mostly valid. Probably most important thing what is missing from it is Splunk Smart Store, but based on your configuration you are not used it. Usually it hard or almost impossible to get data removed based on your exact retention times. As @gcusello already said and you could see it also on that presentation, events are stored into buckets and that bucket expires and removed after all events inside it have expired. For that reason there could be much older data in buckets than you want. How you could try to avoid it? Probably the only way how you could try to manage it, is ensure that all buckets contains only events from one day. Unfortunately this is not possible for 100% of cases. Usually there are situation when your ingested data could contains events from several days (e.g. you start with new source system and ingest also old logs etc.). One thing what you could try is set hot bucket parameters maxHotSpanSecs = <positive integer> * Upper bound of timespan of hot/warm buckets, in seconds. * This is an advanced setting that should be set with care and understanding of the characteristics of your data. * Splunkd applies this limit per ingestion pipeline. For more information about multiple ingestion pipelines, see 'parallelIngestionPipelines' in the server.conf.spec file. * With N parallel ingestion pipelines, each ingestion pipeline writes to and manages its own set of hot buckets, without taking into account the state of hot buckets managed by other ingestion pipelines. Each ingestion pipeline independently applies this setting only to its own set of hot buckets. * If you set 'maxHotBuckets' to 1, splunkd attempts to send all events to the single hot bucket and does not enforce 'maxHotSpanSeconds'. * If you set this setting to less than 3600, it will be automatically reset to 3600. * NOTE: If you set this setting to too small a value, splunkd can generate a very large number of hot and warm buckets within a short period of time. * The highest legal value is 4294967295. * NOTE: the bucket timespan snapping behavior is removed from this setting. See the 6.5 spec file for details of this behavior. * Default: 7776000 (90 days) maxHotIdleSecs = <nonnegative integer> * How long, in seconds, that a hot bucket can remain in hot status without receiving any data. * If a hot bucket receives no data for more than 'maxHotIdleSecs' seconds, splunkd rolls the bucket to warm. * This setting operates independently of 'maxHotBuckets', which can also cause hot buckets to roll. * A value of 0 turns off the idle check (equivalent to infinite idle time). * The highest legal value is 4294967295 * Default: 0 With those you could try to keep each hot buckets open max one day. But still if/when you are ingesting events which are not from current day those will mesh this! But unless you haven't any legal reason to do this I don't propose you to close every bucket containing max events from one day. This could lead you to another issues e.g. with bucket counts in cluster, longer restart etc. times. r. Ismo 

If you can change the URL parameters then you can create a subsearch that takes the ms parameters as parameters e and l. In the subsearch you can do the division and rename the fields earliest and latest. When passed out of the subsearch they will be treated as earliest and latest

One old post where has presented some kind of workaround https://community.splunk.com/t5/Monitoring-Splunk/Why-splunkd-cannot-read-input-files-created-in-source-folder/m-p/184598 Maybe this helps or not?

I can paste those values as URL parameters. So, I can have this URL as input: https://my.splunkcloud.com/en-GB/app/my_app/search?q=search%20index%3Dkubernetes_app%20env%3Dproduction%20service%3Dmy-service&display.page.search.mode=smart&dispatch.sample_ratio=1&earliest=1710525600000&latest=1710532800000

So, it depends on how you are getting these values and including them in your search. Please provide more details. (You may be able to use Splunk to preprocess your values in a subsearch, but it depends where they come from.)

Your search assume that requestid has already been extracted into a field in the index. If you want to just do a string search based on the requestids, try something like this index=blah [search index=blah "BAD_REQUEST" | rex "(?i) requestId (?P<search>[^:]+)" | table search | dedup search] The field search (and query) are given special treatment for subsearches in that the field name is not return, just the contents of the field