One-sided swap publication may expose an endpoint before remote completion

[Bossy-Ye]

Hi SeQUeNCe maintainers,

I ran into a behavior around entanglement swapping that I am not sure is intended.

I reproduced this against SeQUeNCe commit fab8dce2eff428a4a9d4c2d6776d95a9f940a7ce. The topology has three routers, A-R-B, with one memory at A and B and two at R. Standard reservation and resource-management rules generate the A-R and R-B input pairs and perform a ket-vector swap with success probability and degradation set to 1.

The classical delay from R to A is 100,000 ps, while the delay from R to B is 200,000 ps. Because of that asymmetry, A processes its swap result first. A's application receives the swapped memory through get_memory as ENTANGLED with B. The application measures A's endpoint with Timeline.quantum_manager.run_circuit, expires A's local reservation rules, and returns the memory using ResourceManager.update(None, memory, RAW).

After the measurement, A and B no longer share a quantum-state group, and A's memory is RAW with its remote fields cleared. B then processes the delayed SWAP_RES. B's application is nevertheless given its memory as ENTANGLED with A, even though A is already RAW and the two endpoints no longer share a quantum-state group.

I am not sure whether get_memory is intended to grant immediate application use while the other swap result is still in flight, or whether applications are expected to wait for a completion signal that I have missed.

Four-point timeline

Time (ps)	Event
2,006,020	A's get_memory receives ENTANGLED with B; the A-B quantum state is still joint.
2,006,020	A measures its endpoint; A and B become singleton state groups.
2,006,020	A returns the endpoint RAW; its remote node and memory are cleared.
2,106,020	B's delayed callback receives ENTANGLED with A while A is RAW and no A-B joint state exists.

Compact observed output

A_callback:            state=ENTANGLED, remote=B, physical_entanglement_present=true
A_after_measurement:   physical_entanglement_present=false, A_state_group=[0], B_state_group=[3]
A_after_RAW_return:    state=RAW, remote_node=null
B_delayed_callback:    state=ENTANGLED, remote=A, A_current_state=RAW, physical_entanglement_present=false
RESULT: REPRODUCED

Reproduction

Save the attached script as minimal_reproducer.py in an environment with the affected SeQUeNCe commit installed, then run:

python minimal_reproducer.py

The result was byte-identical in five consecutive runs with Python 3.12.11.

The reproducer does not directly assign resource metadata or quantum state. It uses callable SeQUeNCe APIs for reservation, swapping, measurement, local rule expiry, and returning the memory as RAW.

Attached script:

minimal_reproducer.py

• Is a swapped memory delivered through get_memory intended to be immediately usable?
• Is there an API or signal indicating that both endpoints have completed the swap?
• Should delayed SWAP_RES processing validate that the remote endpoint still owns the same resource?
• Is this expected behavior, unsupported application usage, an API-contract ambiguity, or an implementation issue?

[formeo]

Answering my own questions after digging into the code — this issue mixes two things,
and only one is a defect.

The classical bookkeeping is correct. After the BSM at R the endpoints are already
projected into a Bell state; the messages only carry the Pauli frame, which commutes
with a Z-basis measurement as far as the joint outcome distribution goes. And B
holding ENTANGLED after A consumed the pair is faithful — B cannot learn about A's
action faster than light. Validating the remote endpoint in delayed SWAP_RES would
model instantaneous knowledge at a distance, so that's the wrong fix. What's missing
is a documented contract: get_memory hands back a locally usable memory, consumption
is unilateral, coordination is the application's job. RELEASE_MEMORY doesn't cover
it — by then the swapping protocol is gone from owner.protocols and the handler
no-ops.

There is a real bug on the path my reproducer touches, though. Memory.reset() clears
state via quantum_manager.set([self.qstate_key], |0>), which rebinds only that key,
leaving partners with a stale State.keys reference that run_circuit resurrects.
My original reproducer missed it because A measures first, which splits the group
cleanly; the plain RequestApp path hits it directly.

Filed as #460 with a reproducer, PR #461 .

Happy to close this one, or keep it open if you'd like the get_memory contract
documented.