feat: Reuse unused tokens for the next offer

[hassnian]

PR Type

• Bugfix
• Feature
• Refactoring

Context

That has to be burned by user, or you can reuse it for the next offer

let's save this cost to the user, by reusing unsued tokens from old offers

• Closes Automatic cancel expired offer and return deposit #10963

Screenshot 📸

• My fix has changed something on UI;

[netlify]

✅ Deploy Preview for koda-canary ready!

Name	Link
🔨 Latest commit	c3996ea
🔍 Latest deploy log	https://app.netlify.com/sites/koda-canary/deploys/674d3def9202060008c5c24e
😎 Deploy Preview	https://deploy-preview-11204--koda-canary.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Jarsen136]

It's definitely a good idea to reuse the unused offer token. However, it need a better way to get the unused nft id.

---

Let me provide an example showing how it may cause chaotic situations.

1. In the beginning you have an expired offer

[ { offerId: 1, nftSn: 1, status: EXPIRED }]

2. Then you try to create a new offer and reuse the unused token

[ { offerId: 1, nftSn: 1, status: EXPIRED },
{ offerId: 2, nftSn: 1, status: ACTIVE }]

3. If you continue to create a new offer

[ { offerId: 1, nftSn: 1, status: EXPIRED },
{ offerId: 2, nftSn: 1, status: ACTIVE },
{ offerId: 3, nftSn: 1, status: ACTIVE }]

In this step, there is already a problem occurred. You may create infinite offer with one nft.

4. More chaos is coming If the offer 2 has been accepted.

[ { offerId: 1, nftSn: 1, status: EXPIRED },
{ offerId: 2, nftSn: 1, status: ACCEPT },
{ offerId: 3, nftSn: 1, status: ACTIVE }]

If you continue to creating a new offer, the current implement will still using nftSn: 1.
However, the nftSn: 1 is not available anymore.
This step would cause problems again.

[ { offerId: 1, nftSn: 1, status: EXPIRED },
{ offerId: 2, nftSn: 1, status: ACCEPT },
{ offerId: 3, nftSn: 1, status: ACTIVE }
{ offerId: 4, nftSn: 1, status: ACTIVE }]

---

Let me know if this example is not clear or it's not possible to happen with the current implement.

[hassnian]

Let me know if this example is not clear or it's not possible to happen with the current implement.

the example you provided would defiantly be an issue if each new atomic swap mapped to an offer in our indexer, which it does not

an offer's id is made of {offeredCollectionId}-${offeredItem}

so when we create a new offer, with a reused token it will override the old offer code

const id = createTokenId(event.collectionId, event.sn)
const final = offer ? await getOrCreate(context.store, Offer, id, {}) : await getOrCreate(context.store, Swap, id, {})

so basically atm you can't have multiple swaps/offers with the same offered item

this is either a bug or by design, cc @vikiival

if it's the former I will make the required changes , otherwise the current implementation should pass the provided case.

[vikiival]

so when we create a new offer, with a reused token it will override the old offer

Yup, that's how it is implemented

https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/nfts/src/features/atomic_swap.rs#L82-L91

Swap is stored inside a map by key - (offeredCollection, offeredItem) - aka same as in our indexer (note: except that that key in rust is tuple and in our case is dash-separated string).

so basically atm you can't have multiple swaps/offers with the same offered item

So yes each, one offered item per desired item