GeezerVison

cursor Bot left a comment

Adds 11 tools covering the Splunk REST API search lifecycle, saved searches,
fired alerts, and index metadata, plus the block, catalog meta, and a
placeholder icon.

Search jobs are modelled honestly as asynchronous: create returns a sid, status
and results are separate calls, and the only synchronous path is the documented
exec_mode=oneshot search. Every request pins output_mode=json because Splunk
defaults to XML, and writes are form-encoded as the API expects.

Auth accepts a bearer authentication token or basic auth against a user-supplied
management URL, with optional /servicesNS owner and app namespacing.

The icon is a placeholder currentColor glyph pending the real brand mark.

… the REST reference

- Read results from `search/v2/jobs/{sid}/results`. The v1 instance is deprecated
  and turned off by default from Splunk Enterprise 9.0.1 / Cloud 9.0.2208 onward,
  so every Get Search Results call was hitting a disabled endpoint. Both versions
  publish the same JSON envelope, so the response mapping is unchanged.
- Stop sending `enable_lookups=0` / `allow_partial_results=0` on every search job.
  Both subBlocks were switches, which report false when untouched, silently
  inverting Splunk's documented default of true. They are now dropdowns that
  default to Yes.
- Add `max_count` to Run Search and Create Search Job so a oneshot search can be
  bounded below the 10000-row default.
- Add `force_dispatch` to Dispatch Saved Search and the documented
  `triggered_alerts`, `trigger_time_rendered`, and `expiration_time_rendered`
  fields to Get Fired Alerts.
- Add Splunk List Apps over `apps/local`, whose response keys are documented; the
  app name is the namespace value the other tools accept.
- Trim user-supplied path segments, pin `output_mode=json` so a query argument
  cannot override it, and default the index-type filter to all, since Splunk
  itself defaults `datatype` to event.

An untouched subBlock serializes as `null`, not `undefined`, so every optional
Splunk field the user left alone was reaching the request:

- `buildSplunkFormBody` and `buildSplunkUrl` skipped `undefined` and `''` but
  not `null`, so `String(null)` sent `earliest_time=null`, `trigger_actions=null`,
  `force_dispatch=null`, and `add_summary_to_metadata=null` on the wire. Each one
  overrode the default Splunk would otherwise have applied. `force_dispatch` and
  `trigger_actions` have no documented default in the REST reference at all, so
  asserting a value for them was unsourced either way.
- Max Results coerced `null` through `Number()` to `0`, and `count=0` is Splunk's
  documented "return every available row". An untouched Max Results therefore
  asked for the whole result set on all six paginated operations instead of the
  documented default of 100.

Record the sourcing gap on Get Fired Alerts: the entity reference for
`alerts/fired_alerts/{name}` says "Request parameters: None" while the sibling
collection endpoint documents `count`/`offset`.

Revert the unrelated whitespace and table-output drift the docs generator swept
in from the base branch.

The dropdown supplies the strings 'true'/'false', but a workflow variable, an
agent tool call, or a block created over the API supplies a real boolean.
Comparing only against the string turned an explicit `false` into `true`, so a
caller who deliberately disabled lookups or partial results got them enabled.
Normalize both forms, and leave an untouched toggle undefined so the field is
omitted and Splunk applies its own default.

…ing sid

Swarm-validated every tool against the Splunk REST reference on help.splunk.com.

- namespacePrefix filled a half-specified namespace with nobody/search. `nobody`
  names the shared-application owner, so `/servicesNS/nobody/myapp` silently hid
  every user-private saved search, alert, and job in that app; supplying only an
  owner pinned the request to the `search` app. The reference gives `-` as the
  wildcard for both nodes ("To indicate all users, all apps, or resources shared
  by all users, use the wildcard dash (-) symbol"). The old behavior was also
  codified in a test, which now asserts the wildcard instead.
- create/dispatch reported success with `sid: null` when no search ID came back.
  Both now fail loudly, and Create Search Job rejects `exec_mode=oneshot` up
  front — the reference says that mode "Does not return the search ID".
- The results and control endpoints can answer with an empty body (204 while a
  job is still running; the control endpoint documents "Returned values: None"),
  where `Response.json()` threw `Unexpected end of JSON input`.
- Get Fired Alerts no longer sends count/offset. `alerts/fired_alerts/{name}`
  documents "Request parameters: None" and, unlike its sibling collection, does
  not carry the pagination note; an unsupported argument can be rejected outright.
- saved/searches now sends the `f` field filter the reference prescribes for it
  ("This endpoint returns an unusually high number of values"). A saved search
  carries well over a hundred content keys; Sim projects 13.
- Get Saved Search fabricated an all-null saved search from an empty feed.
- The switch-typed toggles (Trigger Alert Actions, Force Dispatch, Include Field
  Summary) reached the tools as the raw string 'false' instead of a boolean.
- Corrected the bearer-token version floor (7.3, not 8.x) and the max_count and
  saved-search filter descriptions to what the reference actually documents.

The reference attaches the "unusually high number of values" warning and its f
prescription to the saved/searches collection. The single-entity endpoint returns
one entry, so the filter buys nothing there and its support is not documented.

cursor Bot left a comment