ExceptionResourceInvalidLockHandle, EditSource, WriteSource, CloneObject, ImportFromFile ..

[JaxCZ]

Hello,

• I have created a set up working on local model Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-v2 (RTX 5090).
• I have set up connection to A4H (Development trial system, SAP_ABA 7.51) and installed claude code with Vibing Steampunk MCP server.
• I can see 140+ tools in abap-adt MCP server.

I wanted to try out a single scenario. I have created empty report in A4H, which i want to rewrite with local copy of an existing report.

Login is working fine, locking is working fine, but when it tries to use EditSource, WriteSource, CloneObject, or ImportFromFile, it always ends up failing with an information about lock handling.

"MCP server Vibing Steampunk is unable to retain the lock handle between individual HTTP requests. Each tool call is a separate HTTP request without any shared state."

"When WriteSource is called, it internally generates a lock handle (e.g. CF5375EDE2DEE39EBEB4BF96A3FA648BF6B8B6A9), but this handle is not valid for subsequent write operations on the ADT resource /source/main. The ADT endpoint reports that the lock is invalid or not applied, even though a valid handle was created.

This behavior prevents the use of WriteSource for reliable ABAP object updates, as the lock is not properly associated with the write operation on /source/main."

EDIT: I have also activated https://github.com/marcellourbani/abapfs_extensions , as this issue was reported and already closed. Sadly, this doesn't work for me. It seems like tools for creating / editing code in system don't work for SAP_ABA 7.51 (at least for trial development system 2023). Basic CRUD loop lock/write/unlock doesn't work on this setup.

Best Regards

[oisee]

Fixed in commit 22517d4 on main.

Root cause: CreateTestInclude and UpdateClassInclude consumed a session-bound lock handle but did not request a stateful session on their PUT/POST. The transport routed the write through a fresh HTTP session that had no record of the lock, so SAP returned 423 InvalidLockHandle several seconds after the lock appeared to succeed. Same regression class that LockObject/UpdateSource/DeleteObject were already pinned for; the class-include leaves were missed in the original sweep. EditSourceWithOptions routes test-class and def/impl-include edits through UpdateClassInclude, so editing a class include reproduced the bug 100% of the time.

Fix: add Stateful: true to both RequestOptions. Two new regression tests pin the X-sap-adt-sessiontype header on the captured request so this can't silently regress.

This will land in the next release. If you can build from main and confirm the fix on your system, that would be very helpful — please reopen if you still see the issue.