Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple object with lock and expiration time not removed after locks are expired #2099

Closed
abereziny opened this issue Nov 24, 2022 · 8 comments
Labels
bug Something isn't working I4 No visible changes S4 Routine U2 Seriously planned

Comments

@abereziny
Copy link

abereziny commented Nov 24, 2022

Let say we have:

  1. Current epoch is 100
  2. Simple object with __NEOFS__EXPIRATION_EPOCH=101
  3. Simple object is locked with lock until epoch 103

Steps:
Tick epochs until current epoch = 103
Check object availability

Expected Behavior

Simple object should be removed since locks are gone and object expired

Current Behavior

Simple object continues to present in storage even if we wait additional extra epochs

Tests

in branch feature-abereziny-add-lock-tests-2

  • pytest_tests/testsuites/object/test_object_lock.py#test_expired_object_should_be_deleted_after_locks_are_expired
@alexchetaev alexchetaev added the bug Something isn't working label Dec 16, 2022
@acid-ant
Copy link
Contributor

it works as expected. Fixed help message for parameter here #2169. I've added one extra epoch tick and test passed.

@abereziny
Copy link
Author

Currently it's not working as expected because objects got removed despite of locks
image

@acid-ant
Copy link
Contributor

acid-ant commented Dec 29, 2022

@abereziny it works as expected. It is ok to get not found error in your case, because expiration epoch in lock blocks any action with data on the file system, but do not affect presence of the object in system. Now it is impossible to test.
In other words, it is possible create object with expiration epoch N and lock with M where M > N. Object will be unavailable at N+1 and persists in fs until M+1

@abereziny
Copy link
Author

abereziny commented Dec 29, 2022

@acid-ant I do not agree with that because current behavior have no real practical use case.
Why do we need to lock object which will be unavailable? What's the point?

for example: we have document with expiration, court need this document in the process so it must not be deleted and must be available until process is complete (despite it's expiration), so lock is assigned. If the document is not available - it practically means that lock doesn't work from user point of view.

@abereziny
Copy link
Author

Logged and issue for API to further elaboration

@roman-khimov roman-khimov added U2 Seriously planned S4 Routine I4 No visible changes and removed triage U3 Regular labels Dec 21, 2023
@roman-khimov roman-khimov added this to the v0.42.0 milestone Feb 28, 2024
@roman-khimov
Copy link
Member

@evgeniiz321, do we have any test scenario like this?

@roman-khimov roman-khimov modified the milestones: v0.42.0, v0.43.0 May 22, 2024
@roman-khimov roman-khimov removed this from the v0.43.0 milestone Aug 5, 2024
@roman-khimov roman-khimov closed this as not planned Won't fix, can't repro, duplicate, stale Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working I4 No visible changes S4 Routine U2 Seriously planned
Projects
None yet
Development

No branches or pull requests

6 participants