调用addV()向Gremlin-Server添加顶点后，后续遍历查询不到新增顶点的问题

这个现象是TinkerPop 3.4.x版本非常典型的远程连接配置问题，和你部署的gremlin-server、JanusGraph服务端无关，根本原因是客户端发送的遍历请求没有正确匹配服务端预先注册的全局图遍历源：

• 无论是官方tinkerpop/gremlin-server镜像还是janusgraph/janusgraph镜像，默认启动配置都会在服务端内部注册一个固定名称为g的全局遍历源，这个遍历源绑定到持久化的图存储实例，所有针对这个遍历源的读写操作都会作用到同一个全局共享的图实例上。
• 你当前代码中使用的DriverRemoteConnection.using("localhost", 8182)是简化的快速初始化重载方法，它创建的连接在发送遍历请求时，不会携带「需要使用哪个已注册遍历源执行查询」的标识。
• Gremlin Server的内置路由逻辑规定：收到没有携带遍历源标识的请求时，不会调用全局注册的g遍历源处理，而是会为当前请求临时创建一个完全空的、独立的内存TinkerGraph实例来执行遍历逻辑：
  • 第一次执行g.V().addV("Test").property("a", "b").iterate()时，服务端在这个临时空图上完成了顶点添加操作，遍历执行完毕后这个临时图会被直接销毁，写入的顶点不会留存。
  • 第二次执行全图遍历查询时，服务端又为这次请求新建了另一个全新的空临时图，因此查询返回的顶点数量永远是0，和你观察到的现象完全匹配。

也正是因为JanusGraph的官方镜像同样遵循这套路由逻辑，没有携带遍历源标识的请求同样会被路由到临时空图执行，所以你切换镜像后会复现完全一致的问题。

你需要在初始化远程连接、创建遍历源时，显式指定要匹配服务端注册的g遍历源，不能直接用简化的using()方法跳过连接配置。
具体修改分为两部分：

• 替换原来的openConnection实现，通过结构化配置初始化远程连接，在配置项中明确指定要连接的服务端遍历源名称
• 遍历源创建的逻辑可以保持不变，只要连接层携带了正确的遍历源标识，服务端就会把请求路由到全局共享的图实例上

修改后的openConnection实现示例：

private DriverRemoteConnection openConnection() {
    // 构建连接配置
    Settings settings = Settings.build()
        .addContactPoint("localhost")
        .port(8182)
        // 关键配置：指定匹配服务端已注册的遍历源名称
        .traversalSource("g")
        .create();
    // 打开连接
    return DriverRemoteConnection.open(settings);
}

完成配置修改后，再运行原有业务代码，addV操作写入的顶点会被持久化到服务端全局共享的图实例中，后续的全图遍历就可以正确返回添加的顶点数量1。
这个临时图fallback机制最初是为了支持没有预配置遍历源的极简测试场景，生产环境中如果忽略了遍历源名称的配置，就一定会遇到"写入不生效、查询永远为空"的异常问题。

内容的提问来源于stack exchange，提问作者Roman Puchkovskiy