Skip to content

fix: ADDON-91029 scope observability app.conf lookup to the owning add-on - #470

Open
Sudesh0119 wants to merge 3 commits into
developfrom
fix/observability-app-scope
Open

Sudesh0119 wants to merge 3 commits into
developfrom
fix/observability-app-scope

Conversation

@Sudesh0119

@Sudesh0119 Sudesh0119 commented Oct 27, 2026 •

Copy link
Copy Markdown

Summary

Telemetry could report the wrong add-on name and version (ADDON-91029). ObservabilityService._read_ta_info() read app.conf without scoping it to an app, so on a host with several add-ons it could pick up another add-on's [id] stanza. For example, the GCP add-on reported itself as Splunk_TA_cyberark 1.2.0.

The fix:

  • solnlib now works out which add-on it belongs to from where it is installed (etc/apps/<app>/...).
  • It reads only that add-on's app.conf.
  • If [id] name is missing, it uses the app folder name instead.
  • If the add-on can't be found, telemetry is skipped and an INFO line is logged, so no wrong identity is reported.

Compatibility

  • No public API or method signature changes. The only addition is a private helper, splunkenv._get_app_name_from_path.
  • Add-ons that pass ta_name / ta_version, or that override StanzaObservabilityRecorder._get_or_create_service (Salesforce, GCP PR #1027), behave the same as on 8.2.0.

Test plan

  • Unit tests: the lookup is scoped to the owning add-on, the right add-on wins when several are installed, the folder-name fallback works, and an undetectable add-on gives no telemetry and no error
  • Side-by-side check of 8.2.0 and this branch with several add-ons installed (lib/, aob_py3, and lib/3rdparty install folders): identity is now correct, and explicit identity and subclass overrides behave the same
  • Check on a Splunk instance with several add-ons installed

🤖 Generated with Claude Code

@Sudesh0119
Sudesh0119 requested a review from a team as a code owner October 27, 2026 08:48
@Sudesh0119 Sudesh0119 self-assigned this Oct 27, 2026
…d-on

The unscoped app.conf lookup merged every installed app, so telemetry
could be labelled with another add-on's name and version. Detect the
bundling app from solnlib's install path and scope the lookup to it.
No public API or method signature changes.

Co-Authored-By: Claude Code <noreply@anthropic.com>
@Sudesh0119
Sudesh0119 force-pushed the fix/observability-app-scope branch from 707a332 to 0d589ed Compare October 27, 2026 09:09
Comment thread solnlib/splunkenv.py Outdated
Comment thread solnlib/splunkenv.py Outdated
Comment thread solnlib/observability.py Outdated
Sudesh0119 and others added 2 commits October 27, 2026 20:39
solnlib's own __file__ is already symlink-resolved (sys.path[0] is
realpath'd), and SPLUNK_ETC may be relocated. Detect the app from the
main script first, fall back to solnlib's path, and accept SPLUNK_ETC.

Co-Authored-By: Claude Code <noreply@anthropic.com>
Prefer the outermost etc/apps match, compare paths case-insensitively on
Windows, tolerate a missing sys.argv or path errors, and keep detection
failures inside _read_ta_info so the solnlib-path fallback still applies.

Co-Authored-By: Claude Code <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants