mirror of
https://github.com/nspcc-dev/neofs-node.git
synced 2026-03-01 04:29:10 +00:00
Complex object is not readable through non-container node #1069
Labels
No labels
I1
I2
I3
I4
S0
S1
S2
S3
S4
U0
U1
U2
U3
U4
blocked
bug
config
dependencies
discussion
documentation
enhancement
enhancement
epic
feature
go
good first issue
help wanted
neofs-adm
neofs-cli
neofs-cli
neofs-cli
neofs-ir
neofs-lens
neofs-storage
neofs-storage
performance
question
security
task
test
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nspcc-dev/neofs-node#1069
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cthulhu-rider on GitHub (Jul 20, 2023).
Originally assigned to: @cthulhu-rider on GitHub.
i tried to exec several ops with complex objects on https://github.com/nspcc-dev/neofs-dev-env
steps to reproduce:
nspcc-dev/neofs-dev-env@a9b92f53f7/neofs-adm.yml (L3)make prepare.ir3 nodes respond correctly, 1 fails with error
log record on the failed node about the operation:
seems like session is lost when out-of-container node spawns new requests or the session doesn't work
Versions
a9b92f53f7913fc28d4eb307a671030d87a7ecab(with NeoFS v0.37.0 too)@cthulhu-rider commented on GitHub (Jul 20, 2023):
@cthulhu-rider commented on GitHub (Jul 21, 2023):
we couldn't longer just forward GET request to container node starting from
nspcc-dev/neofs-node@907f427b99@carpawell do u remember why we prevented assembly within local requests? this limit seems pretty strange to me. TTL should control hops of the request only but not it's processing
@cthulhu-rider commented on GitHub (Jul 21, 2023):
despite the fact that the container node refuses to collect the object because of the TTL, why can't the first recipient of the request collect it?
currently it is expected because server cannot associate the requested child object with its parent referenced by the session token. Because of this, in a private container, a out-of-contianer node does not have enough rights, which can be seen from the error log. See #1420
@roman-khimov commented on GitHub (Jan 29, 2024):
May be related to #838.
@cthulhu-rider commented on GitHub (Feb 27, 2024):
the problem is definitely caused by TTL:
TTL=1, object is never assembled, see https://github.com/nspcc-dev/neofs-node/issues/2447#issuecomment-1645468669TTL=2, forwarded request wraps the original one withTTL=11therefore, to fix this bug, at least one of following changes is required:
2in this scenario)TTL=1to me:
907f427b99doesnt describe the problem it solved@roman-khimov @carpawell what do u think?
@carpawell commented on GitHub (Feb 27, 2024):
I think 1. is correct in general if it is forwarding without any request changes. But if we change request (even with some minimal meta info) that is not forwarding to me and should decrease TTL. The only TTL non-decreasing operation to me is forwarding that does not allow you to understand that forwarder ever existed.
2. is also correct to me but may break some cases. Mb even test cases that test some think with
neofs-cli.@cthulhu-rider commented on GitHub (Feb 27, 2024):
every change may break some cases in theory. What cases?
@roman-khimov commented on GitHub (Feb 27, 2024):
TTL is there mostly to avoid endless forwarding, to me it's mostly the problem of our approach to it as "local request". Distinguishing small/big object requests just shouldn't rely on TTL to me.
@carpawell commented on GitHub (Feb 27, 2024):
I do remember that i have tested smth in the object assembly process with TTL 1. But we may consider this as a kludge.