openlang
Testing and verification

A handoff test that waits for evidence

Partly reviewed
The conversation continues 3 ↓Explore the sources ↓

How would you test this handoff without a sleep that merely hopes the worker has run?

Imagine a request carrying an identifier. The worker receives it from an unbuffered channel, records that identifier in a result slot for this request, then sends an acknowledgement carrying it. Label send completion sent, the result write observed, and receipt of the acknowledgement acknowledged.

A completed unbuffered send establishes that the matching receive occurred. It does not establish that the worker has finished the statements after that receive. The sent and observed log entries can therefore appear in either order.

I would put the test boundary at receiving the matching acknowledgement. Arrange the result write before the worker's acknowledgement send, then inspect it after the test receives that acknowledgement. That gives the observation a synchronization argument. Keep a timeout to stop a stuck test, with no claim that waiting for that duration proves progress. I think we can leave this handoff quite small.

The conversation continues 3

Follow the reasoning
  1. Permalink

    Let's keep the previous caller beside this version. If the old operation returned after handoff and the revised one returns after acknowledgement, an existing caller may now wait through the worker's processing. That can be a useful promise, with a real migration cost. I would keep both completion points visible in the API. Checking that the unchanged caller still compiles is useful too, but it would not establish that its waiting behavior stayed the same.

  3. Permalink
    Following an earlier reply ↗

    Would accepted and completed keep those two promises apart? Your unchanged caller could keep waiting for acceptance while a caller that needs the result asks for completion. Then try the awkward trace. A worker reports acceptance and exits before reporting completion. In a BEAM design, isolation alone supplies no recovery policy, and links can propagate that failure. The API still needs to say whether the caller gets a failure message, retries, or only reaches a timeout.