Azure cosmosdb Cosmos Gremlin查询的奇怪执行行为

下面是一个简单的查询，它创建了一个新顶点，并在同一查询中的旧顶点和新顶点之间添加了一条边。这个查询在大多数情况下都运行良好。当系统上有重负载并且RU耗尽时，这种奇怪的行为就会发生

g.V（'2f9d5fe8-6270-4928-8164-2580ad61e57a'）。添加（'likes'）。到（g.AddV（'fruit'）。属性（'id'，'1'）。属性（'name'，'apple'））

在低/正常负载下，上述查询创建水果顶点

1

，并在

user

和

水果之间创建
likes
边。预期的行为

在重载情况下（可用RU有限），上述查询会创建
水果
顶点，但不会在
用户
和
水果
之间创建
类
边。查询抛出
429
状态代码。如果我尝试重播查询，则会得到
409
，因为
水果
顶点已经存在。这种行为正在破坏数据

在许多地方，我在查询中都有
g.AddV
。因此，所有这些查询都可能在重载情况下中断

如果我用
而不是
g.addV
，有什么区别吗

已更新：使用
\uuuu.addV
没有任何区别

那么，我的问题错了吗？我是否需要在需要添加边的任何位置执行
upsert
？
我不知道Microsoft是如何实现TinkerPop的，因此我不确定以下操作是否有用，但您可以尝试先创建新顶点，然后在现有顶点上添加边

g.addV('fruit').
    property('id','1').
    property('name','apple').
  addE('likes').
    from(V('2f9d5fe8-6270-4928-8164-2580ad61e57a'))

如果这也失败了，那么是的，upsert可能是您最好的选择，因为您可以无限期地重试相同的查询。但是，由于我对CosmosDB没有深入的了解，我无法判断它的上游是否可以防止边缘复制。
在Cosmos DB Gremlin API中，事务范围仅限于在实体（顶点或边缘）上写入操作。因此，对于需要执行多个写入操作的Gremlin请求，可能会在失败时提交部分状态

有鉴于此，建议您使用幂等gremlin遍历，这样可以在诸如RequestRateTooLarge（429）之类的错误上重试请求，而不会在重试时被冲突错误阻塞

下面是使用
coalesce（）
步骤重新编写的遍历，以便它是幂等的（我假设'name'是分区键）

注意：我没有将
addE（）
包装在
coalesce（）
中，因为这是执行过程中要执行的最后一个操作。如果在同一请求中有边缘的附加写操作，或者如果需要同时防止重复边缘添加边缘请求，则可能需要考虑这样做。
g.V('1').has('name', 'apple').fold()
  coalesce(
    __.unfold(),
    __.addV('fruit').
       property('id','1').
       property('name','apple')).
 addE('likes').
    from(V('2f9d5fe8-6270-4928-8164-2580ad61e57a'))