[BUG] Lock acquired successfully but rejected as invalid on the immediate follow-up create request (HTTP 423 ExceptionResourceInvalidLockHandle)

[IVMFaBa]

What happened?

Every write operation that follows the lock → create pattern fails on the second request. The initial lock request succeeds and returns a real, non-empty lockHandle. The immediately following create/POST request that reuses this exact lockHandle is rejected by SAP with HTTP 423 and ExceptionResourceInvalidLockHandle, saying the lock handle could not be established for the object.

This is not object- or name-specific: it reproduces identically for bw_create_infoarea (no parent/no activity dependencies) and for bw_create_infoobject (CHA, various names), so it does not seem to be caused by a naming conflict, a pre-existing lock on a specific object, or an authorization issue on a specific object type (read access via bw_get_infoarea / bw_get_infoobject works without any problem, only the lock → create sequence fails).

BW object type and tool

• bw_create_infoarea
• bw_create_infoobject (type CHA)

Both fail identically. Read-only tools (bw_get_infoarea, bw_get_infoobject, bw_list_contents) work fine throughout.

Steps to reproduce

1. Call bw_create_infoarea with a new, unused InfoArea name under an existing parent InfoArea.
2. Observe the error:

   POST /sap/bw/modeling/area/<name>?lockHandle=<handle> → HTTP 423
   <exc:exception ...><type id="ExceptionResourceInvalidLockHandle"/>
   <message lang="EN">Lock handle for object AREA <NAME> could not be created</message>
   

3. Repeat with bw_create_infoobject (CHA) under an existing, unlocked InfoArea - same error, different object name each time (ruled out per-name locking conflicts).
4. Retried multiple times over ~15 minutes, including after confirming no other user/session (Eclipse BWMT) had the target InfoArea or any object inside it open in change mode. Same result every time.

Expected behavior

The lockHandle returned by the ?action=lock request should remain valid for the immediately following ?lockHandle=<handle> create request within the same client session, per the documented flow in bw-client.ts (Lock → Read → Modify → PUT/POST → Activate → Unlock).

System information

• SAP BW version: BW/4HANA 3.30115 (package $TMP)
• HDB3: 2.00.079.08.1766434523
• Claude client: Claude Desktop, via MCP connector
• Node.js version: v24.15.0
• Connector version: 0.9.2 (per package.json at time of testing)

Additional context

Looking at src/bw-client.ts, I noticed two details that might be related to the root cause, and wanted to flag them in case they're relevant:

1. lock() is called with sessionType = 'stateful_enqueue' for creation flows (activity_context: 'CREA'), which sets X-sap-adt-sessiontype: stateful_enqueue on that request. The subsequent create() call, however, does not pass/override sessionType at all and therefore falls back to the client's default header value X-sap-adt-sessiontype: stateful (set once in the constructor). If the backend ties the enqueue lock context to the specific session-type value used to open the stateful session, this mismatch between the two requests (stateful_enqueue vs stateful) could plausibly cause the backend to treat them as two different session contexts, invalidating the lock in between.

2. Separately (possibly the same underlying cause, possibly not): the existing comment in bw-client.ts -

   "Basic Auth is only sent during the initial CSRF fetch to establish the session. All subsequent requests use the session cookie only - sending Basic Auth on PUT causes SAP to create a new stateless session, invalidating the lock handle."

describes exactly this symptom ("invalidating the lock handle"), which suggests this failure mode is already known to be possible under certain conditions. In our case Basic Auth reuse doesn't appear to be the trigger (session cookie should be intact across the two calls, per the code), so if this is the same failure mode, there may be another path that loses session continuity between lock() and create()/put() - e.g. behind a reverse proxy / SAP Web Dispatcher without server affinity for stateful sessions on the network path between the MCP host and the backend.

We haven't been able to determine yet whether this is infrastructure on our end (Web Dispatcher/session affinity) or a connector-side issue, but wanted to report the exact reproducible symptom (lock succeeds, immediate reuse of that same handle is rejected) in case others hit this too or it points to something fixable on the connector side (e.g. aligning the session-type header between lock() and the following create()/put() call).

Happy to provide additional raw request/response captures if useful.

[dnic-dev]

Thanks for the detailed report. I could not reproduce this on my side: the lock → create sequence via bw_create_infoarea (new, unused name — both at root level and under an existing parent InfoArea) completes successfully, no HTTP 423.

You tested with connector version 0.9.2. Could you retry with the current v1.0.0 (npm install -g bw-modeling-mcp@1.0.0) and let me know whether it still occurs?

If it persists on v1.0.0, the symptom (lock returns a valid handle, the immediate follow-up request rejects it) most likely points to missing session affinity on the network path — a Web Dispatcher / load balancer without stickiness for stateful ADT sessions — which would need to be checked on the infrastructure side. Happy to dig further once we know the v1.0.0 result.