Feat/unpaid containers handling#3650
Conversation
|
Still not sure about dropping container immediately after it is unpaid. How long to wait? |
a143206 to
c0f3e98
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #3650 +/- ##
==========================================
+ Coverage 27.34% 27.35% +0.01%
==========================================
Files 658 659 +1
Lines 41713 41807 +94
==========================================
+ Hits 11407 11438 +31
- Misses 29246 29309 +63
Partials 1060 1060 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
c0f3e98 to
65295a5
Compare
65295a5 to
b2a9c45
Compare
ee1efdf to
20f8020
Compare
c226022 to
698ca3c
Compare
cmd/neofs-node/container.go
Outdated
|
|
||
| p.statuses[cID] = int64(ev.Epoch) | ||
| } else { | ||
| l.Debug("container status has changed to paid", |
There was a problem hiding this comment.
Info?
Consider the following scenario as well:
- container gets "unpaid" status
- all data is deleted from nodes
- its size is zero, so there are no settlements to make
- but its status is still "unpaid" even if owner has some balance
Can this be a problem?
There was a problem hiding this comment.
Info?
hm, i considered "soon be deleted" as an important log, while "everything now ok" as a debug. but dont mind INFO
- its size is zero, so there are no settlements to make
i guess, there we should make a zero report in the next epoch. i can suggest dropping everything about unpaid container, but keep its (0,0) statistics in metabase, then this will be reported, and its status will be changed back. what do you think? any immediately forced report may be the 4-th (prohibited) in this epoch, and we cannot be sure it will be successful
There was a problem hiding this comment.
Let's move this into a separate issue.
| // nodes that maintain objects inside the container. Always sends a notary | ||
| // request with Alphabet multi-signature. Always awaits transaction inclusion. | ||
| func (c *Client) SettleContainerPayment(cID cid.ID) error { | ||
| func (c *Client) SettleContainerPayment(epoch uint64, cID cid.ID) error { |
There was a problem hiding this comment.
But ultimately it's controlled by balance contract, right? I mean double-payment prevention.
There was a problem hiding this comment.
what i meant in this commit: if epoch duration is short enough, it was impossible to pay for a container twice in two or more close epochs, cause tx's hash was the same. this could be seen in our tests. but if you mean that the contract should not allow paying twice per epoch, i do not see what would stop it. is it a problem?
There was a problem hiding this comment.
It sure is, contracts must ensure payment correctness. Submit an issue for contracts, but it's not top priority now.
698ca3c to
90a97c8
Compare
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Implementation of nspcc-dev/neofs-contract#531. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Calculate nothing on the Alphabet side, only send payment transactions for containers. Closes #3357. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Closes #774. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Do not log if nothing to report; report total number of containers found; fix success number log; do not confuse reader with a general logs in singular form. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
This allows debugging problems much easier compared to hiding errors. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Use epoch as a nonce to be able to transfer the same amount of tokens to storage nodes more than once. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
Naming is the same as in `require` package. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
No dropping yet for the first feature release. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
90a97c8 to
5056ef6
Compare
… enabled Refs #3650. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
… enabled Refs #3650. Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
No description provided.