Stamp diluting doesn't change the depth

[mattiaz9]

Context

bee 1.6.2 (mode: dev & restricted)

Summary

After diluting a stamp the TTL is reduced but the depth remains unchanged

Expected behavior

The stamp depth should change to the one specified in the api call

Actual behavior

The depth doesn't change

Steps to reproduce

• Create a stamp (eg: amount: 10, depth 16)
• Dilute the stamp with depth 17 (/stamps/dilute/[batchid]/17)

Possible solution

🤷‍♂️

[istae]

Hi there, Do you mind posting the response after you create the stamp using /stamps/{ID}? I ask because the amount you posted as an example is so small, the batch may actually expire really quickly.

Keep in mind that when a stamp is diluted, the event from the chain backend has to be received first for the stamp to be updated.

[acud]

@istae this is in dev mode, which might suggest that some of the expected callbacks between the abstractions are not happening as expected

[mattiaz9]

Hi there, Do you mind posting the response after you create the stamp using /stamps/{ID}? I ask because the amount you posted as an example is so small, the batch may actually expire really quickly.

Keep in mind that when a stamp is diluted, the event from the chain backend has to be received first for the stamp to be updated.

These are my logs before and after dilute:

{ 
  batchID: "3cc15e387e4922ce4de5f359c0cc138d3f5d21d679e2c17efd8d1aa3242f6d5a", 
  utilization: 0, 
  usable: true, 
  label: "", 
  depth: 16, 
  amount: "482", 
  bucketDepth: 0, 
  blockNumber: 0, 
  immutableFlag: false, 
  exists: true, 
  batchTTL: 63176702 
}

after:

{ 
  batchID: "3cc15e387e4922ce4de5f359c0cc138d3f5d21d679e2c17efd8d1aa3242f6d5a",
  utilization: 0,
  usable: true,
  label: "", 
  depth: 16, 
  amount: "482", 
  bucketDepth: 0, 
  blockNumber: 0, 
  immutableFlag: false, 
  exists: true, 
  batchTTL: 31588350 
}

[aloknerurkar]

So I dont think we should fix this. dev mode is not meant to test for correctness. This should only be used to check API responses for integration on the app side. The postage related APIs are talking to an actual blockchain. These have no meaning when it comes to dev mode as the node is not connected to blockchain or in any network.

The idea is to move developers to use the testnet to actually test their integrations with the postage contract. Right now in dev mode the stamps created are dummy stamps. Topping them up or diluting them has no meaning. The only reason creating a dummy stamp is supported is because this allows you to test the upload functionality. Although all this is happening in-memory on the dev node.

If we add functionality into these mock classes, then we need to start unit testing them. This PR will be substantial in that case.

@istae @agazso

[mattiaz9]

@aloknerurkar I see your point, but right now dilute already changes the TTL, so it's very weird that cannot change a batch depth, which is just the exact number you pass in the endpoint, right?. Whether they are dummy or not, they should reflect a standard behaviour IMO.

[aloknerurkar]

If you are testing postage contract logic (topup/dilute etc), you should be using the actual contract and not a dummy implementation. I dont see any value in testing your logic using dev mode for this.

Dev mode was mostly created to see how the output would look. So it tries to spit out dummy values. But the actual values dont have any significance. Having any dependence on these values would be wrong imo.

There is already a testnet which can be used. We actually spend time maintaining it and monitoring it as well. So I would encourage you to start using it. The bugs you find there would be much more valuable to us.

[Cafe137]

I could successfully dilute my stamp on mainnet with Bee 1.7.0, but it takes about a minute for the API to report to new value. Please note the timestamps.

15:56:05 swarm-cli 0 s stamp dilute --stamp 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c --depth 23   
Stamp ID: 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c
Depth: 22
Amount: 28350016

16:03:56 swarm-cli 0 s stamp show -v 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c                    
Looking up postage stamp 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c...
Stamp ID: 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c
Label: test
Usage: 0%
TTL: 249310 seconds
Depth: 22
Bucket Depth: 16
Amount: 28350016
Usable: true
Utilization: 0
Block Number: 23626932
Immutable Flag: false

16:04:25 swarm-cli 0 s stamp show -v 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c
Looking up postage stamp 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c...
Stamp ID: 05e69442c78bf6bb894b09decf148d9b14d82b4faf2e28d6e02b2afde884ef7c
Label: test
Usage: 0%
TTL: 124637 seconds
Depth: 23
Bucket Depth: 16
Amount: 28250298
Usable: true
Utilization: 0
Block Number: 23626932
Immutable Flag: false

[agazso]

It seems that there are multiple issues are here. I opened a separate issue for the non-dev mode case, when diluting takes long time: https://github.com/ethersphere/bee/issues/3193

In the case of the dev mode after a discussion with the dev team the conclusion was that for now the dilute endpoint will report an error and it is not going to be implemented, because making the same behavior in dev mode would be a significant effort. However it would be good to see this in the future, so PRs are welcome.

[ghost]

This issue in dev mode will be resolved later.