D-031 How are the § 5.6.1 commitment-attempt and § 5.6.3 dependency statements checked?

What the schemas do

Each is an obligation of the seller: it rejects, replays, or conflicts a commitment attempt, which no single line item shows.

Options

• obligations Chosen

  Each is an obligation of the seller: it rejects, replays, or conflicts a commitment attempt, which no single line item shows.

• rules

  Each is a rule on the commitment object.

Why

Each statement says what the seller does with a commitment attempt or a publication: it rejects a stale version, an expired proposal or price, an unmet requires, or a cycle; returns the current version or the original result; and never interprets an idempotency_key. Deciding any of them needs the seller's state or the other line items of the proposal, not one payload, so none is a rule on the commitment. That holds for the two requires checks too, though they read only line items. The specification makes a proposal and a line item two documents (§ 2), and names no key of the proposal that holds its line items (D-028, D-033), so no payload holds both a line item's requires and the line_item_id of every line item in its proposal version. Whether each reference names a line item of the same proposal and version, and whether the references form a cycle, can't be decided from one payload. The meanings of all_of[] and any_of[] are the same kind of check, on the set of line items in one commitment.

What we ask the specification to state

Define the commitment attempt as a message, with its response and its error, so these requirements can be tested. As written, they are behavior with no payload to check. Name the key of a proposal that holds its line items. Then the two requires checks become rules on that document, with test vectors. One check is that each reference in all_of[], any_of[], and min_commitment[].line_item_id names a line item of the same proposal version. The other is that the references form no cycle.

The specification lines it rests on

Each line is quoted as the record pins it. Expand an item to read the quote.

main

• § 5.6.1, a requirement L299 at 44dfaaf

  A request carrying an idempotency_key already seen MUST return the original result and MUST NOT create a second commitment.

With the open PRs

• § 5.6.1, a requirement L301 in #73

  The seller MUST NOT interpret it.

• § 5.6.1, a requirement L304 in #73

  The seller MUST reject a new commitment attempt whose version is not the current version of the proposal named by proposal_id, whose proposal is past valid_until, or whose pricing[].price_valid_until has passed.

• § 5.6.1, a requirement L306 in #73

  The rejection MUST return the current version number, so the buyer can fetch it again.

• § 5.6.1, a requirement L307 in #73

  These checks MUST be deterministic, as for idempotency_key.

• § 5.6.1, a requirement L310 in #73

  For a replay from the same buyer of a commitment attempt the seller has already processed, with the same idempotency_key and the same commitment terms, the seller MUST return the original result and MUST NOT create a second commitment.

• § 5.6.1, a requirement L314 in #73

  Reusing an idempotency_key with different commitment terms MUST produce an explicit conflict and MUST NOT create or modify a commitment.

• § 5.6.3, a requirement L326 in #70

  Line items that MUST all be in the same commitment

• § 5.6.3, a requirement L327 in #70

  Line items of which at least one MUST be in the same commitment

• § 5.6.3, a requirement L344 in #70

  References in requires MUST point to line items in the same proposal and version.

• § 5.6.3, a requirement L346 in #70

  A seller MUST reject a commitment that includes a line item whose requires is unmet.

• § 5.6.3, a requirement L347 in #70

  This check MUST be deterministic.

• § 5.6.3, a requirement L352 in #70

  A seller MUST reject a proposal at publication if requires references form a cycle.