get_user_transports returns empty while list_transports returns same data (follow-up to #9)

[AnOffeElco]

Summary

On the same system / same user, the hyperfocused universal SAP tool routes list_transports and get_user_transports return inconsistent results:

• SAP(action="system", params={"type": "list_transports"}) → correctly returns all 3 modifiable workbench requests for user EOFFERMANNAN
• SAP(action="system", params={"type": "get_user_transports", "user_name": "EOFFERMANNAN"}) → returns "No workbench requests found. No customizing requests found."

Case-insensitivity was ruled out (user_name: "eoffermannan" yields the same empty result).

This looks like a follow-up to the closed #9 (which I filed for v2.21.0): that fix appears to have repaired list_transports but left the user-filtered path broken — or the user-filtered path has regressed since.

Environment

• vsp version: v2.32.0-1-g4265032-dirty (the release currently working around the v2.36 lock-handle regression — see Regression v2.32 → v2.36: 423 ExceptionResourceInvalidLockHandle on S/4HANA 758 write path #110)
• OS: macOS (Darwin 25.4.0, arm64)
• Backend: SAP S/4HANA 2023, System ID WIE, client 010
  • sapRelease: 758, kernelRelease: 75I, abapRelease: 758
• SAP_ENABLE_TRANSPORTS: "true", SAP_FEATURE_TRANSPORT: "on", SAP_MODE: "expert"

Reproduction

SAP(action="system", params={"type": "list_transports"})

returns:

[
  {
    "number": "WIEK911568",
    "owner": "EOFFERMANNAN",
    "type": "K",
    "status": "D",
    "statusText": "Modifiable",
    "target": "/Z_CUS/",
    "targetDesc": "Workbench Request",
    "changedAt": "20260415195636"
  },
  {
    "number": "WIEK911412",
    "owner": "EOFFERMANNAN",
    ...
  },
  {
    "number": "WIEK910087",
    "owner": "EOFFERMANNAN",
    ...
  }
]

But the user-filtered variant:

SAP(action="system", params={"type": "get_user_transports", "user_name": "EOFFERMANNAN"})

returns:

Transports for user EOFFERMANNAN:

No workbench requests found.

No customizing requests found.

Same system, same session, same user, same minute — one route sees the data, the other doesn't.

Suspected cause

Two paths likely call different ADT endpoints or parse different response shapes:

• The working list_transports appears to hit the endpoint fixed in Transport API returns 406 - Wrong Accept header for CTS endpoints #9 (the one that originally returned 406 with a wrong Accept header).
• The still-broken get_user_transports may still use the old endpoint / old Accept header, or parse the workbench/customizing bucket from a path that's no longer populated after the Transport API returns 406 - Wrong Accept header for CTS endpoints #9 fix.

A git log v2.21.0..v2.32.0 on the transport client code, filtered on GetUserTransports / user-filtering logic, should isolate the issue quickly.

Workaround

Use list_transports and filter owner == "<user>" client-side. That's what I did here.

Happy to provide full verbose traces or CSRF/cookie dumps if a debug flag emits them.