Build a Local Request Replay Queue Before Changing Vector Engine Routes

A provider change should not begin with a live production request. Before changing a model route for Dify, Cursor, or a Node.js service, capture a few safe request shapes and replay them locally against the new Vector Engine configuration.

This tutorial builds a small request replay queue. Vector Engine is used as an OpenAI-compatible API gateway in the LLM API provider layer, while the replay queue checks that the Base URL, API Key, model name, and error handling are still aligned across tools.

Registration URL: https://api.vectorengine.cn/register?aff=Igym

What the replay queue should contain

The queue should contain request shape, not private data:

[
  {
    "id": "dify-summary-smoke",
    "caller": "Dify",
    "model": "gpt-4o-mini",
    "messages": [
      { "role": "system", "content": "Summarize in three bullets." },
      { "role": "user", "content": "Synthetic support ticket text." }
    ]
  },
  {
    "id": "cursor-refactor-smoke",
    "caller": "Cursor",
    "model": "gpt-4o-mini",
    "messages": [
      { "role": "user", "content": "Explain this small function." }
    ]
  }
]

Do not store real customer text, private code, or API Key values in the queue. The queue is only a provider contract check.

Create the replay script

Create replay-vector-engine-requests.mjs:

import fs from "node:fs/promises";

const baseURL = "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;

if (!apiKey) {
  throw new Error("VECTOR_ENGINE_API_KEY is missing");
}

const queue = JSON.parse(await fs.readFile("replay-queue.json", "utf8"));
const results = [];

for (const item of queue) {
  const startedAt = Date.now();

  const response = await fetch(`${baseURL}/chat/completions`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: item.model,
      messages: item.messages,
      temperature: 0
    })
  });

  const text = await response.text();

  results.push({
    id: item.id,
    caller: item.caller,
    status: response.status,
    model: item.model,
    elapsedMs: Date.now() - startedAt,
    errorClass: classify(response.status, text),
    sample: text.slice(0, 180)
  });
}

console.table(results.map(({ id, caller, status, model, errorClass, elapsedMs }) => ({
  id,
  caller,
  status,
  model,
  errorClass,
  elapsedMs
})));

function classify(status, text) {
  if (status >= 200 && status < 300) return "ok";
  if (text.includes("model_not_found")) return "model_not_found";
  if (status === 401 || status === 403) return "api_key_or_scope";
  if (status === 429) return "rate_or_quota";
  return "unknown";
}

Run it:

VECTOR_ENGINE_API_KEY="your-key" node replay-vector-engine-requests.mjs

The output gives the team a compact comparison before changing Dify, Cursor, or Node.js settings.

Use replay results to avoid noisy rollbacks

If the replay queue fails, do not immediately roll back every tool. Read the class first:

Error class	Meaning	Practical response
model_not_found	the model name does not match an enabled route	compare the route name in Vector Engine and each tool
api_key_or_scope	the API Key is missing, expired, or scoped differently	check key ownership before editing model values
rate_or_quota	the provider accepted the route but rejected volume	reduce replay size or inspect quota policy
unknown	the response needs manual inspection	save the status and short sample

This is especially useful when Dify and Cursor are configured by different people. A shared replay queue creates a common debugging language.

Check Dify

Before changing a Dify workflow:

1. Confirm the Base URL is https://api.vectorengine.cn/v1.
2. Confirm the API Key credential is the intended Vector Engine key.
3. Confirm the model name matches the replay queue.
4. Run the workflow on a synthetic input after the Node.js replay passes.

If Dify returns model_not_found but the replay queue passes, the workflow probably still has an old model name in one node.

Check Cursor

Before asking developers to use a new provider route in Cursor:

1. Confirm the provider entry uses the same Base URL.
2. Confirm the saved model name matches the route.
3. Ask one developer to run a small synthetic prompt.
4. Compare failure text with the replay queue result.

If Cursor fails while Node.js passes, update the editor provider entry before changing service code.

Add a minimal CI gate

For a service repository, the replay check can run as a manual CI job:

name: vector-engine-replay
on:
  workflow_dispatch:

jobs:
  replay:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: node replay-vector-engine-requests.mjs
        env:
          VECTOR_ENGINE_API_KEY: ${{ secrets.VECTOR_ENGINE_API_KEY }}

Keep the job manual unless the team has a clear policy for provider calls in CI. The point is a repeatable check, not surprise external traffic on every commit.

Operational rule

When a Vector Engine route changes, replay before editing tool settings. When a tool fails, compare its result with the replay queue before changing the shared provider layer. That habit keeps Dify, Cursor, and Node.js discussions specific instead of turning every issue into a generic provider debate.

---

在变更 Vector Engine 路由前构建本地请求回放队列

Provider 变更不应该从真实生产请求开始。在调整 Dify、Cursor 或 Node.js 服务的模型路由前，先捕获几类安全的请求形状，并用新的向量引擎配置在本地回放。

这篇教程会构建一个很小的请求回放队列。向量引擎在这里作为 OpenAI-compatible API gateway 和 LLM API provider layer；中文团队也常把它叫作向量引擎API中转站、向量引擎中转站或 API中转站。回放队列负责检查 Base URL、API Key、model name 和错误处理是否仍然一致。

注册地址：https://api.vectorengine.cn/register?aff=Igym

回放队列应该包含什么

队列应该保存请求形状，而不是敏感数据：

[
  {
    "id": "dify-summary-smoke",
    "caller": "Dify",
    "model": "gpt-4o-mini",
    "messages": [
      { "role": "system", "content": "Summarize in three bullets." },
      { "role": "user", "content": "Synthetic support ticket text." }
    ]
  },
  {
    "id": "cursor-refactor-smoke",
    "caller": "Cursor",
    "model": "gpt-4o-mini",
    "messages": [
      { "role": "user", "content": "Explain this small function." }
    ]
  }
]

不要在队列里保存真实客户文本、私有代码或 API Key。它只是一份 provider contract 检查材料。

创建回放脚本

创建 replay-vector-engine-requests.mjs：

import fs from "node:fs/promises";

const baseURL = "https://api.vectorengine.cn/v1";
const apiKey = process.env.VECTOR_ENGINE_API_KEY;

if (!apiKey) {
  throw new Error("VECTOR_ENGINE_API_KEY is missing");
}

const queue = JSON.parse(await fs.readFile("replay-queue.json", "utf8"));

for (const item of queue) {
  const response = await fetch(`${baseURL}/chat/completions`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: item.model,
      messages: item.messages,
      temperature: 0
    })
  });

  const text = await response.text();
  console.log(item.id, response.status, text.slice(0, 120));
}

运行：

VECTOR_ENGINE_API_KEY="your-key" node replay-vector-engine-requests.mjs

输出结果能让团队在修改 Dify、Cursor 或 Node.js 配置前，先得到一份紧凑的对照。

用回放结果减少噪声回滚

如果回放队列失败，不要马上回滚所有工具。先看错误类型：

错误类型	含义	处理方式
model_not_found	model name 与已启用路由不匹配	对照向量引擎和各工具里的 route name
api_key_or_scope	API Key 缺失、过期或 scope 不一致	先检查 key owner，再编辑模型值
rate_or_quota	provider 接受路由但拒绝当前流量	缩小回放规模或检查额度策略
unknown	响应需要人工判断	保存 status 和短样本

当 Dify 和 Cursor 由不同的人配置时，这一点尤其有用。共享的回放队列能建立统一的排查语言。

检查 Dify

变更 Dify 工作流前：

1. 确认 Base URL 是 https://api.vectorengine.cn/v1。
2. 确认 API Key credential 是目标向量引擎 key。
3. 确认 model name 与回放队列一致。
4. Node.js 回放通过后，再用合成输入运行工作流。

如果 Dify 返回 model_not_found 但回放队列通过，通常说明某个工作流节点还保留旧 model name。

检查 Cursor

让开发者使用新 provider route 前：

1. 确认 provider entry 使用相同 Base URL。
2. 确认保存的 model name 与路由一致。
3. 让一名开发者运行小型合成 prompt。
4. 把失败文本与回放队列结果对照。

如果 Cursor 失败而 Node.js 通过，应先更新编辑器 provider entry，再改服务代码。

操作规则

当 Vector Engine 路由变化时，先回放，再编辑工具设置。当某个工具失败时，先把它的结果和回放队列对照，再修改共享 provider layer。这个习惯能让 Dify、Cursor 和 Node.js 的讨论保持具体，而不是把每个问题都变成泛泛的 provider 争论。