isoArcade.setBounds does not update octree

[Niko-O]

As found here I set the 3D world bounds of my world like this in the preload callback:
game.physics.isoArcade.setBounds(-30, -30, 0, 100, 100, 150);
And in the render callback I use octree to display the world bounds:
game.debug.octree(game.physics.isoArcade.octree, '#FFFFFF');
game is an instance of Phaser.Game
This results in the following being displayed:

Which is wrong because the white wireframe does not actually reflect the world bounds. In fact, whatever I pass to setBounds, the white wireframe stays the same size.

So after spending a while on navigating through the code I found out that the setBounds function (which is part of the Phaser.Plugin.Isometric.Arcade class, see source code) calls the setTo function on this.bounds which is a Phaser.Plugin.Isometric.Cube, simply passing on its parameters.
However, octree uses a completely different property in its own class to hold the current world bounds (see source code), which is never updated.
Since octree updates its data in the reset function, which is called in the constructor, I tried game.physics.isoArcade.octree = new Phaser.Plugin.Isometric.Octree( game.physics.isoArcade.bounds.x, ......); directly after the call to setBounds from above and the bounds are correctly displayed:

But I don't think this is the correct way of doing it. the setBounds function should handle changes to the bounds on its own. Maybe octree is not the only part which should be updated whenever the world bounds change.

So: Is this a bug?
It seems reasonable to me to assume that I can change the world bounds with a single call and not have to worry about other stuff getting updated correctly. If that's not the case though: Where am I expected to find that information? Googling for "phaser isometric world bounds" and the like, I found multiple websites mentioning game.world.setBounds(x, y, width, height); (e.g. this and this), which does not really make sense when using isometric world space. There are also a few abandoned questions about this (e.g. this).
I was lucky to find this post mentioning the 3D version of the setBounds function.

[lewster32]

This is likely an oversight/bug based on essentially porting the Arcade physics from Phaser without fully understanding its workings. I'll possibly take a look at this if I get time, though someone with active use of the plug-in (such as yourself) may be better suited to submitting a PR to fix this.

[Niko-O]

I could submit a pull request to fix this particular case, but I don't know the details either because I am only using it for a very small project, so my guess is as good as yours.