large API call fails: Invalid target object in edit handler

[philipp_kreidl]

When trying to send an rather large API call (atomic) to Panorama I receive this error message <Fail: Invalid target object in edit handler>

What I found out so far:

• API calls work correct if the "payload" (element content) is below a specific size, but there are also 2 different error situations
  • where the error message above is shown
  • where no error message is shown but a 500 internal server error is logged in the chrome console.
• Happens for multiple types, tested and confirmed with: Security Rules & Address objects
• Content of the API call is not the problem, I can split it manually and send it from Expedition in 2 runs by hand (same content but split into 2 api calls)
• A single character makes the difference if it works or fails

Please see this picture for the size of the API call payload which causes problems:

Should the picture not work:

Lower equal 101162 bytes > works
Between 101163 and 101210 bytes > Does not work but no error message is shown. Chrome console throws 500 error
Above 101211 bytes > Expedition error message shown

I'm not sure if the problem is caused by expedition or by Panorama itself. I wasn't able to recreate the same API call expedition is doing with linux.
Expedition 1.1.73.1
Panorama 9.0.9

I've edited large security rulesets in the past and it worked, not sure since when this is broken.

Thanks for your help

[GustafBerg · Accepted solution]

Hello again,

I had a chat with Palo Alto and Expedition about this through our support case. Turns out it was not related to Panorama PanOS 9.x.

The expedition tool is using the POST to send the big amount of data, and in that case the limit should be 5MB, which is far from the limit you were seeing.

It seems to have been an issue in the PHP code handling a very large body.

Update to Expedition (1.1.83.2) fixed all our issues using the built in API Output Manager.

[philipp_kreidl]

I can confirm that the API call for the security rules now works as expected.

But 1.1.83.2 introduced a different issue for me, I will create a new post for that issue.

Thanks @GustafBerg