feat(splunk): add Splunk Enterprise and Cloud integration - #6743
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryMedium Risk Overview The block exposes 12 operations (run search, create/get/cancel job, get results, list/get/dispatch saved searches, fired alerts, indexes, apps) with API-key auth (bearer token, optional basic auth and namespace fields). Param mapping normalizes dropdown/switch toggles via Also adds Reviewed by Cursor Bugbot for commit f76a211. Configure here. |
Contributor
Greptile SummaryThe PR adds a Splunk Enterprise and Cloud integration with block configuration, twelve management API tools, generated registry metadata, tests, icons, and documentation.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| apps/sim/blocks/blocks/splunk.ts | Defines the Splunk block and correctly preserves typed boolean false values while omitting untouched toggles. |
| apps/sim/blocks/blocks/splunk.test.ts | Covers typed and string toggle values, untouched fields, pagination coercion, parameter remapping, and operation registration. |
| apps/sim/tools/splunk/utils.ts | Implements namespace-aware URLs, authentication, null-safe serialization, and response normalization. |
| apps/sim/tools/splunk/requests.test.ts | Exercises Splunk URL and form-body serialization behavior. |
| apps/sim/tools/registry.ts | Registers the new Splunk tools with the central execution registry. |
| apps/docs/content/docs/en/integrations/splunk.mdx | Documents the integration’s operations, inputs, and outputs. |
Reviews (4): Last reviewed commit: "fix(splunk): keep the f field filter on ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Collaborator
Author
Collaborator
Author
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 5b4f159. Configure here.
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.
waleedlatif1
force-pushed
the
feat/splunk-integration
branch
from
August 16, 2026 00:01
5b4f159 to
5e11d9a
Compare
Collaborator
Author
Collaborator
Author
|
@cursor review |
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.
Collaborator
Author
Collaborator
Author
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit f76a211. Configure here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/servicesby default,/servicesNS/{owner}/{app}when an owner or app is set) and always pinoutput_mode=jsonso a caller cannot flip the response back to XML.Three things worth a reviewer's attention:
search/v2/jobs/{sid}/results. The v1 instance of that endpoint is deprecated and turned off by default from Splunk Enterprise 9.0.1 / Splunk Cloud 9.0.2208 onward, so every call was hitting a disabled endpoint. Both versions publish the same JSON envelope (init_offset,messages,preview,results), so the response mapping is unchanged.enable_lookupsandallow_partial_resultswere being sent as0on every search job. Both wereswitchsubBlocks, and an untouched subBlock does not resolve to "unset" — so the request silently inverted Splunk's documented default oftruefor both. They are dropdowns defaulting to Yes now. The same class of bug affected every other optional field: an untouched subBlock resolves tonull, and the form/query serializers only skippedundefined, soString(null)putearliest_time=null,trigger_actions=null, andforce_dispatch=nullon the wire. Max Results was worse —Number(null)is0, andcount=0is Splunk's documented "return every available row", so an untouched Max Results asked for the entire result set on all six paginated operations instead of the documented default of 100. Both serializers now dropnullalongsideundefined, and the coercion guards against it.count/offsetonalerts/fired_alerts/{name}. The entity reference for that endpoint says "Request parameters: None", while the sibling collection endpointalerts/fired_alertsdocuments both. They are exposed on the assumption that the shared Atom collection pagination applies; an instance that ignores them just returns the full set. This is recorded in a TSDoc note on the tool.Everything else — endpoints, parameter names, defaults, and response field names — is taken from the Splunk REST API reference. Response fields are mapped individually rather than dumped, with Splunk's
0/1booleans normalized and both theentry[]andfeed.entry[]collection envelopes handled.Type of Change
Testing
Tested manually. Added unit tests for the URL and form-body serializers covering the null-drop behavior, the pinned
output_mode, explicit falsy values, and namespace selection.Checklist