[helpcodeai]

Fixes from the 14 Oct review, plus three Odoo/SAP items from two stuck Odoo 19 users and the Postman form-body bug that #1057 fixed for HAR.

1. Cloudinary: OAuth refresh failed minutes after each authorization (our bug)

Root cause. Tool calls through /mcp built the engine config without connectorId, for every engine type, and parsed a fresh authConfig from the registry's JSON string on every call. As a result, OAuth2TokenService:

• keyed its cache and mutex on a new "unsaved" key each time, so nothing was cached or locked;
• did not re-read the stored refresh token from the database;
• never stored the renewed one.

Cloudinary's MCP server issues 5-minute access tokens (expires_in: 300) and rotates the refresh token. The first renewal after five minutes succeeded and its new refresh token was dropped. The next renewal replayed the spent one and got invalid_grant: Invalid or expired refresh token.

The cloud logs show it:

• The refresh failures on /mcp read token refresh failed: with no for connector ….
• Connector cmv6t4iry… was re-authorized at 06:11:43. Its 06:32 call renewed successfully, yet the row was never updated: no lastRefreshedAt, and updated_at is still 06:11:43.

The "two refreshes 1 s apart" were two Test connection clicks after the token was already dead. #916 had fixed Test connection and discovery, not the tool-call path.

Fix.

• The tool-call path passes connectorId to the engines. Credentials built from {{amcp.*}} caller variables stay unkeyed, because they differ per caller.
• A renewal for a saved connector runs under a Postgres transaction-scoped advisory lock (pg_advisory_xact_lock(hashtext('amcp:oauth2-refresh:<id>'))).
  • It reads the stored refresh token and writes the rotated one on that transaction's connection, before the lock is released. Using one connection means a full pool cannot deadlock against itself.
  • This covers the two backends of a blue/green deploy. A renewal that waited on the lock takes the token the other process stored instead of spending the refresh token again. After a 401, it does so only if that token was obtained after the refused request.
  • If the write does not survive the transaction, the token is written again outside it.
  • If no connection is free for the lock within 3 s, the renewal runs unlocked, as before.
• The MCP bridge now recognises the SDK's 401. SdkHttpError carries the status in data.status, and its message is only the body (Error POSTing to endpoint: {"error":"invalid_token"…}), so the old message.includes('401') check never fired and the renewal after a rejection never ran.

Tests. oauth2-token.service.refresh-race.spec.ts uses a rotating fake provider and a shared fake table with advisory-lock semantics:

• five-minute tokens across several renewals with a fresh authConfig per call;
• two concurrent calls in one process;
• two processes renewing at once;
• the same two processes without the lock, which lose the connector;
• the write failing under the lock;
• the transaction failing after the token endpoint answered;
• no connection free for the lock;
• adopting a token after a 401.

The SQL was checked against a real Postgres 16 with two Prisma clients.

Existing connectors. cmv6t4iry043u01k3iuqwrbpo and cmv6r9xu100hr01k3zn3ui7vt were re-authorized this morning but will break again within minutes of their next renewal until this is deployed. Rotating OAuth providers on REST or GraphQL tool calls (JTL, Sage, DATEV) were exposed to the same path.

2. weclapp: 400 "unknown property"

About 50 failures over 10 workspaces since 4 Oct. All of them were guessed names in properties, such as customerNumber on orders and invoices, openAmount, salesOrderItems, shippingAddress, unitName, stockQuantity and validUntil.

• Each list tool's properties now starts with "Leave empty (the default)". It then lists real top-level field names from weclapp's API v2 OpenAPI (https://www.weclapp.com/api/openapi_v2.yaml), with the names guessed wrong in production and what to use instead.
• The instructions stop recommending properties on large lists.
• The weclapp error hint now first says to retry without properties.
• No tool renamed. The adapter version changes, so existing installs are offered the update.

3. Odoo: "Invalid apikey" after a day = expired key

Since Odoo 18, API keys expire, and the New API Key dialog preselects 1 Day (the first entry of _selection_duration). Persistent Key is offered to administrators only; other users get at most their group's api_key_duration, which is 90 days for internal users.

In the cloud: 63 JSON-2 Invalid apikey 401s across 5 workspaces, and about 40 JSON-RPC Access Denied across 9 workspaces, in two weeks. Changes, for odoo and odoo-jsonrpc:

• setup steps;
• API key field help;
• verify hints;
• new runtime hints for Invalid apikey and Odoo Server Error: Access Denied.

They say the key has likely expired and to create a new one with Duration "Persistent Key" or the longest duration offered.

Odoo JSON-2 404 (added on request):

• The database-name lookup asked /json/2/web/database/list, which 404s, so it never suggested anything for the JSON-2 adapter. It now asks the origin.
• Before offering the JSON-RPC connector, the check calls the unauthenticated common.version:
  • below 19: offers JSON-RPC;
  • 19 or later: says the database name is wrong and names the right one;
  • Odoo Online's "typo" page: a 404 whose script redirects to odoo.com/typo?domain=… (checked live). In that case the check says the address is not an Odoo database.
• saas~19 versions are parsed. If the version cannot be read, the old hint and suggestion stay.

4. SAP S/4HANA Cloud token URL (added on request)

The instructions gave a BTP XSUAA token URL (…authentication.eu10.hana.ondemand.com/oauth/token), while the field help gave the tenant -api host. Both now point to the Token Service URL shown under the arrangement's Inbound Communication → OAuth 2.0 Details, on https://<tenant>-api.s4hana.cloud.sap/sap/bc/sec/oauth2/token. The base URL example now includes -api too.

A 401 at verify or at runtime lists the four causes:

• token URL;
• a client that is not the arrangement's communication user;
• a missing arrangement;
• a scope.

A 403 names the missing arrangement.

5. SMTP in the self-hosted compose files (#1083)

docker-compose.yml and docker-compose.quickstart.yml list the app environment one variable at a time and left out SMTP_*, so what setup.sh writes into .env never reached the app. Both now pass SMTP_HOST/PORT/USER/PASS/FROM/FROM_NAME/REPLY_TO/SECURE.

The cloud compose already passed them (Mailgun, unchanged).

SMTP_FROM_NAME, which setup.sh and railway.json ask for, was never read. It now names the sender when SMTP_FROM is a bare address. A SMTP_FROM that already has a name wins, so the cloud is unaffected.

A test checks that every SMTP_* the email service reads is passed by both compose files. docker compose config was run on both.

6. Postman import: form bodies sent as JSON

The same bug as the HAR importer (#1057):

• urlencoded bodies now get bodyEncoding: form-urlencoded.
• formdata bodies get form-data (multipart). A file field becomes a { "__file": "$field" } marker that the engine fills from the public URL the caller passes, like Etsy's image upload.
• Body field names __proto__, constructor and prototype are skipped, and form fields are merged in one step instead of keyed writes. This came from CodeQL's remote-property-injection rule on the changed lines.

Checks

• Backend jest: 571 suites passed, 15,090 tests passed (689 skipped are live specs).
• tsc clean for backend and frontend; ESLint clean on all changed files.
• node scripts/validate-adapters.mjs: 405/405.
• node scripts/adapter-count.mjs --check: OK.
• No dependency changes.