XDR "Send using Edge Protocol - XDR" (h)(2) Test 10 — SUT's XDR reaches ETT but card stays "Pending", no captured request, no report (same as Jul 2026 "b1 XDR Sending Cases - Stuck at Pending")

[REDA ELAMRI]

Hi Sai / Nagesh ("Dragon") / Evan,

We're testing 170.315(h)(2) "Send using Edge Protocol - XDR" (Direct > Test By Criteria > H2 > Paragraph (i)(C)), role Sender (HISP-SUT), on a Direct Java RI 8.1.0-based HISP. Our outbound XDR reaches ETT but the test card never leaves "Pending" — this looks like the same recurring edge-XDR issue as the Jun–Jul 2026 thread "b1 XDR Sending Cases - Stuck at Pending" (https://groups.google.com/g/edge-test-tool/c/019ACjcYHlU).

Setup (registered in ETT): Direct From = ett-...@isharedev.xyz, contact email = r.el...@isharemedical.com.

Flow: We enter Direct To Address = ett-...@isharedev.xyz on XDR Test 10 and click RUN. ETT sends a Direct message from testc...@ett.healthit.gov to ett-...@isharedev.xyz. Our HISP receives it, converts to an ITI-41 ProvideAndRegisterDocumentSet-b, and POSTs it over mutual TLS to:
  https://ett.healthit.gov:11084/xdstools/sim/edge-ttp__10/rep/xdrpr

What we've confirmed on our side (with logs):
- ETT's Direct trigger message arrives and is processed.
- We generate a valid SOAP 1.2 ProvideAndRegisterDocumentSet-b: WS-Addressing (Action urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b, MessageID, To), a direct:addressBlock (direct:from, direct:to, direct:metadata-level=minimal), and full IHE XDS DocumentEntry metadata (classCode/typeCode/formatCode/confidentialityCode/healthcareFacilityTypeCode/practiceSettingCode, patientId, uniqueId). No schema (cvc) errors.
- The POST reaches ETT (mutual TLS OK) but returns no synchronous RegistryResponse:Success. Note: an earlier deliberately schema-invalid submission DID return a synchronous RegistryResponse:Failure with cvc errors, so mutual TLS and app-layer processing are working — once the message is valid, we get no synchronous RegistryResponse at all.
- Our outbound egress source IP is 136.35.205.142 (same IP ETT delivered the Direct trigger to).

Symptom: XDR Test 10 stays at "Pending" indefinitely; clicking REFRESH does not advance it to "Awaiting Validation". The LOGS REQUEST/RESPONSE tabs show only a marker ("ran tc 10") with no captured request. No validation report email arrives.

Recent attempts (UTC), for your server-side log lookup on the edge-ttp__10 sim:
- 2026-09-26 03:48:23Z
- 2026-09-26 04:07:51Z
- 2026-09-26 05:27:45Z

What we've already ruled out on our side: metadata level (tried minimal and full), direct:from (tried both testc...@ett.healthit.gov and ett-...@isharedev.xyz), direct:to matches the entered address, source IP matches, TLS/cert (the invalid submission returned a sync Failure), and no trailing spaces / correct case.

Looking at the toolkit source (SimServletFilter / TkListener / XdrReceiverImpl), card advancement depends on the sim's notification callback firing and ETT parsing a Success/Failure — could you please check the edge-ttp__10 sim's transaction log and callback for the timestamps above? Our two hypotheses are :

(A) the sim being deleted/recreated by a re-prime after our POST (wiping the recorded request), or

(B) the callback not firing because the notification properties weren't set on the sim instance our POST reached.

Given the 2026-10-21 certification package freeze / 60-day evidence window, we'd greatly appreciate a timely reset of the edge-ttp XDR simulator (as was done in the Jul 2026 thread) and confirmation that capture is restored. Happy to provide the full outbound SOAP envelope.

Thanks again for your help!!

[REDA ELAMRI]

Update:  i isolated this to the hosted ETT, not our message.

To rule out our side, we stood up a local instance of the NIST XDS Toolkit (xdstools 7.10.0) with a Document Recipient simulator (edge-ttp__10) and sent our HISP's identical ITI-41 ProvideAndRegisterDocumentSet-b at it.

Against the local NIST toolkit, our message:
- is RECORDED in the sim's transaction DB,
- returns a synchronous RegistryResponse with status ...ResponseStatusType:Success (no RegistryErrorList), and
- fires the sim's TRANSACTION_NOTIFICATION callback successfully (the transactionLogBean POST that advances the ETT card).

The same message that ett.healthit.gov's edge-ttp__10 logs as an empty "ran tc 10" with no captured request is therefore fully accepted (recorded + Success + callback) by the identical toolkit locally. That points to the hosted edge-ttp XDR simulator not capturing/advancing our submissions, rather than a defect in our XDR,  the same pattern as the Jul 2026 "b1 XDR Sending Cases - Stuck at Pending" thread.

Could you please reset/restart the edge-ttp XDR simulator and confirm capture is restored for our Test 10 (Direct To Address ett-...@isharedev.xyz)? Recent attempt timestamps (UTC): 2026-09-26 05:27:45Z.

Heads-up on timing: we will be running our certification test runs against ETT shortly, so we need the edge-XDR simulator up and running reliably. We're working against the 2026-10-21 package freeze / 60-day evidence window, so a timely fix would be much appreciated. Happy to provide the full outbound SOAP envelope or any logs you need. Thank you.