refactor(interactive): Add error handling for adhoc queries

[zhanglei1949]

We Introduce boost::leaf for lightweight error handling in the Interactive Ad Hoc Query Service.
For each operator, we refactor it returns a bl::result value, allowing the error to be caught and returned at the most outside, i.e. adhoc_app.cc.

In this PR, we only wrap the errors about UNSUPPORTED UNIMPLEMENTED and BAD_REQUET at operator level. For lower level errors, we still let it crash.

TBD:

• GAE depends on boost::leaf via vineyard, but we don't want to depend on vineyard, so a new submodule is introduced, is this ok?

Fix #4189

We will continue to resolve these UNSUPPORTED and UNIMPLEMENTED errors, by covering all combination of all params and operators in physical plan.
TODO #4190

[zhanglei1949]

That code is no longer used.

[github-actions]

Please check the preview of the documentation changes at
https://78e97e4c.graphscope-docs-preview.pages.dev

[zhanglei1949]

@yecol @sighingnow @siyuan0322 Is there any better way to introduce boost::leaf for Interactive? Ensure it is compatible with the dependency structure of vineyard and GAE.

[siyuan0322]

@yecol @sighingnow @siyuan0322 Is there any better way to introduce boost::leaf for Interactive? Ensure it is compatible with the dependency structure of vineyard and GAE.

If the development container and builder dockerfile is shared with analytical engine, then boost::leaf is already installed. So maybe you could find boost::leaf in system path first in CMake?

If its for users to install manually, then installing boost::leaf could be a prerequisite.

[zhanglei1949]

@yecol @sighingnow @siyuan0322 Is there any better way to introduce boost::leaf for Interactive? Ensure it is compatible with the dependency structure of vineyard and GAE.

If the development container and builder dockerfile is shared with analytical engine, then boost::leaf is already installed. So maybe you could find boost::leaf in system path first in CMake?

If its for users to install manually, then installing boost::leaf could be a prerequisite.

I got it. But one thing is unclear to me - even though leaf.hpp is installed by vineyard in the graphscope-dev container and the base image of the graphscope interactive, the path is relative to where vineyard is installed, specifically ${VINEYARD_INSTALL_PREFIX}/include/vineyard/contrib/boost. Without find_package(vineyard), we cannot determine the installed prefix of vineyard.

[yecol]

Please comfirm with Dongze: .graphscope_env should address the paths issues.

[siyuan0322]

@yecol @sighingnow @siyuan0322 Is there any better way to introduce boost::leaf for Interactive? Ensure it is compatible with the dependency structure of vineyard and GAE.

If the development container and builder dockerfile is shared with analytical engine, then boost::leaf is already installed. So maybe you could find boost::leaf in system path first in CMake?
If its for users to install manually, then installing boost::leaf could be a prerequisite.

I got it. But one thing is unclear to me - even though leaf.hpp is installed by vineyard in the graphscope-dev container and the base image of the graphscope interactive, the path is relative to where vineyard is installed, specifically ${VINEYARD_INSTALL_PREFIX}/include/vineyard/contrib/boost. Without find_package(vineyard), we cannot determine the installed prefix of vineyard.

We could do a link in the dockerfile.

[lidongze0629]

@zhanglei1949 @dashanji Vineyard does rely on boost leaf as a thirdparty and install to /opt/vineyard/include/vineyard/contrib/boost/leaf directory. I suggest we could install boost leaf in global, and both vineyard and interactive try to use it first;

[dashanji]

@zhanglei1949 @dashanji Vineyard does rely on boost leaf as a thirdparty and install to /opt/vineyard/include/vineyard/contrib/boost/leaf directory. I suggest we could install boost leaf in global, and both vineyard and interactive try to use it first;

Yeah, vineyard will find the boost leaf package first. If not exist, then use the thirdparty code.
https://github.com/v6d-io/v6d/blob/main/modules/graph/CMakeLists.txt#L85-L102

I think interactive could do the same.

[zhanglei1949]

@zhanglei1949 @dashanji Vineyard does rely on boost leaf as a thirdparty and install to /opt/vineyard/include/vineyard/contrib/boost/leaf directory. I suggest we could install boost leaf in global, and both vineyard and interactive try to use it first;

Yeah, vineyard will find the boost leaf package first. If not exist, then use the thirdparty code. https://github.com/v6d-io/v6d/blob/main/modules/graph/CMakeLists.txt#L85-L102

I think interactive could do the same.

Great! So correct me if I'm wrong:

1. First we need boost leaf installed globally in graphscope-dev image. And also gsctl should be able to install boost leaf globally, when installing dependencies for Flex Interactive(or for other components)
2. Interactive will expect a boost leaf package installed globally. If that fails, interactive will tell the user to install boost leaf. (Although we may try to find available boost/leaf.hpp somewhere, from my point of view, it would be somehow adhoc.)
3. Interactive will NOT introduce boost leaf as a third party dependency.

@lidongze0629 @dashanji @luoxiaojian @yecol