Just recently getting error with bundlefiles custom command

[wryanthomas]

Not sure when bundlefiles command stopped working, but it might have been when upgraded to latest Little Admins Helper (v1.7.0) or when we recently got upgraded to Splunk Cloud 10.4.2604.  But it now gives this error:

Error in 'bundlefiles' command: HTTPError at "/opt/splunk/etc/apps/sa-littlehelper/bin/../lib/splunklib/binding.py", line 1411 : HTTP 500 bad character (49) in reply size -- bad character (49) in reply size

[acharlieh]

Hi @wryanthomas ! 

Unfortunately splunklib/binding.py is code out of the Splunk SDK for Python for invoking Splunk REST endpoints. 
https://github.com/splunk/splunk-sdk-python/blob/2.1.1/splunklib/binding.py#L1411

To troubleshoot this more, we would need to figure out which endpoint was being called and why that particular endpoint started throwing a 500 error after the Splunk version upgrade or after the Admin's Little Helper upgrade.

The search.log from the Job Inspector If I remember correctly should have a stacktrace which could help point to a particular particular endpoint. Additionally/alternatively we should be able to find access logs from your current search head, to itself and/or to other SHC members for the 500 error in index=_internal as well. 

Other thoughts include what architecture are you on (SH vs SHC), and does it always throw the error or does it change with certain flows? (e.g. target=local vs target=all when on a SHC... or bundle=latest vs bundle=computed, etc. )

If you're willing to share which stack information and would like me to take a look deeper... drop me a note as mentioned on the Admin's Little Helper app page: [email protected] / [email protected] 

[wryanthomas]

We are on a fully-managed Splunk Cloud stack (Victoria Experience).  This issue was resolved by uninstalling the app, and reinstalling it.

[acharlieh]

Glad you were able to fix things. 

I also wound up with a case relayed to me today around a cloud customer where bundlefiles also wasn't working after a major change to their stack... turned out that customer had also installed an app that had an older copy of Admin's Little Helper.... 

So the new search command hitting an old copy of my custom REST endpoint... and problems ensued...  a 400 error as opposed to a 500 error in that case... but still interesting.