The discount tool was writing its own receipts

Flow

When the gateway says it already ran

1. 1Refusal comes back⌄

   The gateway says it has seen this key, but not what the tags are now.

2. 2Read the live list⌄

   Fetch the store's packages and find the row by all of its IDs.

3. 3Row is missing⌄

   The tags are unknown, so the refusal stays an error.

4. 4Tags match⌄

   Report success with no new write sent.

5. 5Tags differ⌄

   Keep the error and say the live tags do not back up the write.

Tagging a package was something the discount tool could claim when the store's system had told it nothing.

The tool marks down old stock by putting a discount tag on a package in the live store inventory. The tag sets the price at the register. My system sends the change through a gateway I run. The gateway does the write and should reply with the tags as they are now. That reply is the only proof the write worked.

A receipt copied from the order form

The code that read the reply had a bad fallback. If the tags were missing, it used the tags I asked for and called it a win. A plain "ok" looked just like a real write.

Now a missing list is an error, and so is a list that doesn't match the request. The tests cover both with a fake gateway.

Two stories behind one refusal

The gateway refuses a request key it has seen before and says it already ran. That can mean the first try worked and the reply got lost. Or it can mean the key was saved and the write failed. You can't tell which by guessing.

So on that refusal the tool reads the live package list, finds the row by all its IDs, and compares tags. If they match, it reports a success that sent no new write. If they don't, or the row is gone, it stays an error.

A key that remembered the content forever

The key was built from the content alone: this package, these tags. So if someone took the tag off by hand and I asked again later, the gateway would say it had already done it. The change is to the key.

The key now includes the request's own ID along with the content.

A resend of one request is still caught. A new request is a new write.

The bulk screen counts finished packages as done

The bulk screen used to call packages that already had the right tags "skipped." They're now counted as done, with no write sent. Packages missing IDs still show as skipped.

Fakes, lag and retries

The tests use fakes. I haven't seen the real refusal, and I don't know if the live list can lag behind a write. If a caller makes a new request ID on every retry, the gateway can't catch the repeat. My guess is the write replaces the whole tag set, so that's probably fine.