[w3c/payment-request] Clarify the behavior of calling PaymentResponse.complete() while [[retryPromise]] is pending (#795)

I'm working on implementing payment retry in WebKit, and I'm seeing an unexpected failure when running retry-method-manual.https.html:

> FAIL Calling complete() while a retry() is in progress results in an InvalidStateError. promise_test: Unhandled rejection with value: object "InvalidStateError: The object is in an invalid state."

I think I've implemented complete() as-specified, so I'm not sure whether the test is wrong or the spec is.

What's happening in the test is:

- The test calls `response.retry()`.
    - UA sets `response.[[retryPromise]]` to a new promise.
- The test calls `response.complete("success")`.
    - UA sets `response.[[complete]]` to `true`.
    - UA throws an `InvalidStateError` because `response.[[retryPromise]]` is not null.
- The user accepts payment.
    - UA resolves `response.[[retryPromise]]`.
- The test calls `response.complete("success")`.
    - UA throws an `InvalidStateError` again, this time because `response.[[complete]]` is `true`.

The test seems to expect that response should remain non-complete after the first call to `complete()` and therefore the second call to `complete()` should succeed since the retry promise had settled.

The spec says that `response.[[complete]]` should be set to `true` before checking if `response.[[retryPromise]]` is non-null. So that means the second call to `complete()` must throw an `InvalidStateError` even if `response.[[retryPromise]]` had been settled.

Should we defer setting `response.[[complete]]` to `true` until later in the algorithm? Or should we change the test to expect an exception on the second call to `complete()`?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/795