Dump when changing with a wrong transport request number

[raaleksandr-epam]

If a tool is called with a transport request number different from the one that is locking the object, it dumps.

Prerequisites:
An object (e.g., a class) is locked in a transport request.

Steps:

1. Run a tool, e.g., update the class with a different transport request number

Result:
Error 500

In ST22, there is a dump with a description that the object is locked in a different TR number.

[fr0ster]

Hi @raaleksandr-epam — thank you for reporting this! It's a valid scenario that we've now addressed.

Root cause: When an object is already assigned to transport request TR-X and you call an update tool with a different transport request TR-Y, SAP rejects the operation with an ABAP dump (HTTP 500) because the object cannot be reassigned to a different transport.

What's new in v2.6.0:

We've added a new read-only tool — ListTransports — that lets you check available transport requests before performing any create or update operation.

How to prevent this issue:

Before calling any create/update tool, call ListTransports to see your available transport requests:

{
  "user": "YOUR_SAP_USER",
  "modifiable_only": true
}

The response will list all your modifiable transport requests. Pick the correct one and pass it as transport_request to the create/update tool.

Additionally in v2.6.0:

• Fixed transportRequest forwarding in all high-level create and update handlers (related issue Not able to create or update. Reads are working. #11).
• Upgraded @mcp-abap-adt/adt-clients to 1.2.2.

Please update to v2.6.0 and let us know if this resolves your workflow. Thanks again for helping improve the project!

[fr0ster]

@raaleksandr-epam Could you clarify which specific object types you're experiencing this issue with?

For example, with classes it's possible that the package is assigned to one transport request while the class itself is on a different one — which makes the "wrong TR" scenario more nuanced.

Are you seeing this primarily with classes, or also with other object types (views, tables, domains, function modules, etc.)? Any specific reproduction steps with exact object types would help us address this properly.

Thank you!

[fr0ster]

v2.6.1 is now published on npm with the ListTransports tool and all transport request forwarding fixes.

Could you please try updating and let us know how it works for your scenario?

We are also planning to run integration tests on an on-premise system tomorrow to verify the full workflow.

Thank you for your patience!

[fr0ster]

Update: v2.7.0 published

This issue may also be mitigated by the fix in v2.7.0. One of the reasons an object could end up on the wrong transport request was the missing masterSystem attribute in ADT XML requests. Without it, SAP on-premise systems could bind the object to an unexpected transport request during creation — then subsequent updates with a different TR would cause the HTTP 500 dump.

v2.7.0 now correctly passes masterSystem and responsible to all create/update operations.

If you're on an on-premise system, please add SAP_MASTER_SYSTEM to your .env file:

SAP_MASTER_SYSTEM=YOUR_SYSTEM_ID

Replace YOUR_SYSTEM_ID with your SAP system ID (e.g., DEV, QAS — find it via transaction SM51).

Please update and let us know if this reduces the frequency of wrong-TR issues:

npm install -g @mcp-abap-adt/core@latest

[fr0ster]

Update: v2.7.1 — added SAP_MASTER_SYSTEM and SAP_RESPONSIBLE to CLI help (--help) and .env.example for easier discovery.

[fr0ster]

Update: v2.7.5 published

v2.7.4–2.7.5 adds HTTP header support for system context: x-sap-master-system and x-sap-responsible. These headers allow per-request override of SAP_MASTER_SYSTEM / SAP_RESPONSIBLE for HTTP/SSE transport.

This further reduces wrong-TR binding scenarios for on-prem HTTP/SSE setups where no .env file is used.

stdio users are not affected.

npm install -g @mcp-abap-adt/core@latest

[fr0ster]

Update: v3.0.0 published

Key change in this release: Create and Update handlers are now fully separated. Create produces the initial object (without source code), Update writes the source. Previously Create handlers also accepted source code and performed an implicit update step, which could lead to unexpected transport binding conflicts.

This separation makes the transport request flow more predictable and reduces the chance of hitting the wrong-TR scenario described in this issue.

npm install -g @mcp-abap-adt/core@latest

[raaleksandr-epam]

The issue is not reproducible anymore on my end, closing the issue