Fix/drop control call #2873
Fix/drop control call #2873
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2873 +/- ##
==========================================
- Coverage 23.69% 23.61% -0.08%
==========================================
Files 770 770
Lines 44580 44524 -56
==========================================
- Hits 10562 10514 -48
+ Misses 33163 33160 -3
+ Partials 855 850 -5 ☔ View full report in Codecov by Sentry. |
carpawell
force-pushed
the
fix/drop-control-call
branch
from
2aa43f7
to
66b3c52
Compare
|
|
||
| for _, addr := range res.AddressList() { | ||
| inhumePrm.MarkAsGarbage(addr) | ||
| _, err := e.inhumeAddr(prm.addr, inhumePrm) |
There was a problem hiding this comment.
Looks like it was a bit more efficient previously with sorted shards.
There was a problem hiding this comment.
why do you think it is unsorted now?
There was a problem hiding this comment.
e.iterateOverUnsortedShards(func(sh hashedShard) (stop bool) {
in inhumeAddr
There was a problem hiding this comment.
you mean this? it is root object handling, there is no information about link and last objects that can be acquired via root object's ID
|
|
||
| var splitErr *objectSDK.SplitInfoError | ||
| if !errors.As(err, &splitErr) { | ||
| if !shard.IsErrNotFound(err) { |
There was a problem hiding this comment.
This one differs from the two implementations.
There was a problem hiding this comment.
yes, that is the key of my suggestion: why do we differ this logic? we do the same things (and one may always have more or less num of bugs) when delete/inhume objects, why some of them should be collected (if an object is a big one) one way while the other should be handled differently? about this PR: i have improved and fixed a little Inhume some time ago and could not understand why i had do it again one more time when looking at Delete
carpawell
force-pushed
the
fix/drop-control-call
branch
from
66b3c52
to
5ce4023
Compare
carpawell
force-pushed
the
fix/drop-control-call
branch
from
5ce4023
to
bd94a60
Compare
`Inhume` has expanding children functionality since 26704f9. Collecting objects in every method with its own code is error-prone, also `Delete` and `Inhume` are almost the same now. Relates #2822. Signed-off-by: Pavel Karpy <[email protected]>
Children handling has been moved on the engine layer, it searches for links and deletes all the children. There is no need to try it on a layer that even may not have such objects at all (they can be moved, deleted and replicated, etc.). Relates #2822. Signed-off-by: Pavel Karpy <[email protected]>
carpawell
force-pushed
the
fix/drop-control-call
branch
from
bd94a60
to
0cc0c6a
Compare
i thought that |
|
@carpawell worth changelog? the issue occurred in the pub network |
Relates #2822. Signed-off-by: Pavel Karpy <[email protected]>
Not sure I can find correct words about the whole PR. But if you are about the original issue, we may add it, yes. |
carpawell
force-pushed
the
fix/drop-control-call
branch
from
0cc0c6a
to
932e7b0
Compare
Overall, should close #2822, hard to say, there were many commits merged about it, and "problem" objects are already dropped.