esi_panels pane cache fails when generating the ESI-url, making the whole site crash.

It seems like it is used to generate a unique identifier?

I am having the same issue, without panels everywhere (just using panels). Assuming that it will be used to create a unique identifier, I did the following:

  $args = is_object($display->args) ? get_object_vars($display->args) : $display->args;
  $url .= '/' . implode('/', array_keys($args));

  // Always add the current page URL.
  $url .= '/' . base64_encode($_GET['q']);

This sent the error away, and now I see the esi tag baked in the HTML of the pane where I enabled the esi cache. But, to be honest, still don't know if it works as my varnish is not caching at the moment.

Attaching a patch.

patch doesn't apply
i think it has to be done from within the esi directory

Seems patch has no sense.
Normally $display->args could not be an object.
But $display->args[0] is object in most of cases.
As a result implode('/', array_keys($args)) will return '0', which is not pretty useful.

I think idea of add display args should be reviewed. Because i don't see clear way to handle all $display->args values within URL.
It could contain big set of data (nested arrays and etc).

another variant of patch
don't add anything if we have array with NOT string elements

Looks is_scalar() more appropriate here, otoh ...
#4 said

But $display->args[0] is object in most of cases.

so maybe just skip this (0) and research what should be there exactly

+++ b/sites/all/modules/esi/modules/esi_panels/esi_panels.module
@@ -239,7 +239,15 @@ function esi_panels_url($pane, $display) {
+  foreach ($display->args as $arg) {
+    if (!is_string($arg)) {
+      $add_args = FALSE;
+    }

looks that needs break after setting FALSE

Re-generated @uzlov's patch (#5) from esi module root, includes break suggested by @andypost.

This patch existed on a separate thread since 2014, just wasn't marked for review: https://www.drupal.org/project/esi/issues/2219671

Should decide which of these two to use.

I think the other version might be a better option, because it at least adds something if some of the $arg values are strings, rather than skipping all $args. Also when debugging, it provides some direction on where the issue might exist.

Closing in favour of https://www.drupal.org/project/esi/issues/2219671