Idempotency for internal GraphQL API

[sabineschaller]

to not have to worry about duplicate calls

See e.g.: https://shopify.engineering/building-resilient-graphql-apis-using-idempotency

[wilsonianb]

I think the following mutations are already idempotent:

• createAsset
• updateAssetWithdrawalThreshold
• updatePeer
• deletePeer
• addPeerLiquidity
• addAssetLiquidity
• createPeerLiquidityWithdrawal
• createAssetLiquidityWithdrawal
• createAccountWithdrawal
• finalizeLiquidityWithdrawal
• rollbackLiquidityWithdrawal
• createOutgoingPayment
• depositEventLiquidity
• withdrawEventLiquidity
• deleteAllApiKeys
• revokeSession

which leaves the following:

• createAccount
• triggerAccountEvents
• createPeer
• createQuote
• createApiKey
• redeemApiKey
• refreshSession

Should Shopify's indempotencyKey be added as an input field for all mutations for consistency? We currently just have id, eventId, etc serving as an idempotency key.

Do we need to support idempotent quote creation in graphql when it's not supported in Open Payments? (Retrying just results in more work for the server / duplicate quotes.)

[wilsonianb]

@matdehaast :point_up_2: thoughts?

[sabineschaller]

Talked to @matdehaast. He suggests adding the idempotency key to every mutation.

[wilsonianb]

ALL of them? My take is that Shopify post advocates for idempotency keys for making a payment service resilient. Quote ids already act an idempotency keys for creating outgoing payments.

[sabineschaller]

I wonder if it's just easier for the client to just always generate an idempotency key, no matter which mutation is done. I agree that outgoing payments don't need them due to the quote id. But who knows how much longer we will have quotes...