TrueCloudLab/frostfs-node
20
1
Fork 27
Code Issues 100 Pull requests 4 Projects Releases 1 Activity Actions

node: Break notary deposit wait after VUB #1467

Merged
fyrchik merged 1 commit from dstepanov-yadro/frostfs-node:fix/deposit_vub into master 2024-11-05 13:05:55 +00:00
Conversation 2 Commits 1 Files changed 6 +77 -41
dstepanov-yadro commented 2024-10-31 10:15:00 +00:00
Member
Copy link

There is no point in waiting for the transaction to complete after VUB.

There is no point in waiting for the transaction to complete after VUB.
dstepanov-yadro added 1 commit 2024-10-31 10:15:01 +00:00
[#9999] node: Break notary deposit wait after VUB
All checks were successful
Tests and linters / Run gofumpt (pull_request) Successful in 2m14s
Details
DCO action / DCO (pull_request) Successful in 2m27s
Details
Pre-commit hooks / Pre-commit (pull_request) Successful in 2m55s
Details
Vulncheck / Vulncheck (pull_request) Successful in 2m47s
Details
Tests and linters / gopls check (pull_request) Successful in 3m33s
Details
Build / Build Components (pull_request) Successful in 3m43s
Details
Tests and linters / Staticcheck (pull_request) Successful in 3m42s
Details
Tests and linters / Lint (pull_request) Successful in 4m34s
Details
Tests and linters / Tests (pull_request) Successful in 6m52s
Details
Tests and linters / Tests with -race (pull_request) Successful in 6m52s
Details
6fced12a69 
Signed-off-by: Dmitrii Stepanov <d.stepanov@yadro.com>
dstepanov-yadro force-pushed fix/deposit_vub from 6fced12a69 to 1facf94b49 2024-10-31 10:15:42 +00:00 Compare
dstepanov-yadro requested review from storage-core-committers 2024-10-31 10:21:52 +00:00
dstepanov-yadro requested review from storage-core-developers 2024-10-31 10:21:53 +00:00
acid-ant approved these changes 2024-10-31 10:27:39 +00:00
Dismissed
fyrchik reviewed 2024-10-31 11:27:15 +00:00
cmd/frostfs-node/morph.go Outdated
@ -192,2 +192,4 @@
return fmt.Errorf("could not wait for one block in chain: %w", err)
}
currHeight, err := c.cfgMorph.client.BlockCount()
fyrchik commented 2024-10-31 11:27:15 +00:00
Owner
Copy link

This is tricky, because there is some time between TxHalt() and BlockCount()
Consider this scenario:

  1. Check for TxHalt() at Height=VUB-1
  2. New block is accepted, tx is in it.
  3. Wait for one more block
  4. Height = VUB + 1, so we exit.

I think we must make yet another TxHalt request in case currHeight > vub.

Still we may switch endpoint, but this is a more rare event.
Another option would be to make WaitTxPersist(ctx, tx) and do everything under switch mutex.

This is tricky, because there is some time between `TxHalt()` and `BlockCount()` Consider this scenario: 1. Check for `TxHalt()` at Height=VUB-1 2. New block is accepted, tx is in it. 3. Wait for _one more_ block 4. Height = VUB + 1, so we exit. I think we must make yet another `TxHalt` request in case `currHeight > vub`. Still we may switch endpoint, but this is a more rare event. Another option would be to make `WaitTxPersist(ctx, tx)` and do everything under switch mutex.
👍 1
fyrchik commented 2024-10-31 11:42:14 +00:00
Owner
Copy link

Also, can we reuse something from https://github.com/nspcc-dev/neo-go/blob/master/pkg/rpcclient/waiter/waiter.go ?

Also, can we reuse something from https://github.com/nspcc-dev/neo-go/blob/master/pkg/rpcclient/waiter/waiter.go ?
dstepanov-yadro commented 2024-10-31 12:42:36 +00:00
Author
Member
Copy link

Done: make yet another TxHalt request in case currHeight > vub

Done: make yet another `TxHalt` request in case `currHeight > vub`
dstepanov-yadro commented 2024-10-31 12:44:34 +00:00
Author
Member
Copy link

Also, can we reuse something from https://github.com/nspcc-dev/neo-go/blob/master/pkg/rpcclient/waiter/waiter.go ?

Don't think we need one more dependency from neo-go.

> Also, can we reuse something from https://github.com/nspcc-dev/neo-go/blob/master/pkg/rpcclient/waiter/waiter.go ? Don't think we need one more dependency from neo-go.
fyrchik commented 2024-10-31 12:55:26 +00:00
Owner
Copy link

We already depend on the module (and it is external).
And that package canonically solves exactly our problem (I have given 1 error, who knows what else can go wrong).

We already depend on the module (and it is external). And that package canonically solves exactly our problem (I have given 1 error, who knows what else can go wrong).
dstepanov-yadro commented 2024-10-31 13:28:08 +00:00
Author
Member
Copy link

Then why do you ask, if in fact you insist on using it?

Then why do you ask, if in fact you insist on using it?
dstepanov-yadro commented 2024-10-31 13:55:49 +00:00
Author
Member
Copy link

fixed

fixed
fyrchik commented 2024-10-31 14:18:08 +00:00
Owner
Copy link

That seemed like an obvious choice, and I wanted to know if there was any reason not to make it.
I find yet-another-dependency (which in fact is already is in go.mod) argument weak.

That seemed like an obvious choice, and I wanted to know if there was any reason not to make it. I find yet-another-dependency (which in fact is already is in `go.mod`) argument weak.
dstepanov-yadro commented 2024-10-31 14:52:27 +00:00
Author
Member
Copy link

obvious choice

I don't see an obvious choice: to use this interface, which I didn't even know about (and not only me), I had to add a structure and two methods, and also add a dependency on a package that can be changed at any time (do you know how neo-go supports backward compatibility?)
The implementation itself also raises questions:

  • the context should not be stored in the structure:
RPCPollingBased interface {
		Context() context.Context
  • there is no check for the length of the array Execution: res.Executions[0]
  • the number of retries const PollingBasedRetryCount = 3 is not configured
  • why are retries used only to request the number of blocks, but not for application log
  • ...
> obvious choice I don't see an obvious choice: to use this interface, which I didn't even know about (and not only me), I had to add a structure and two methods, and also add a dependency on a package that can be changed at any time (do you know how neo-go supports backward compatibility?) The implementation itself also raises questions: - the context should not be stored in the structure: ``` RPCPollingBased interface { Context() context.Context ``` - there is no check for the length of the array `Execution: res.Executions[0]` - the number of retries `const PollingBasedRetryCount = 3` is not configured - why are retries used only to request the number of blocks, but not for application log - ...
dstepanov-yadro force-pushed fix/deposit_vub from 1facf94b49 to ce13b46281 2024-10-31 12:41:18 +00:00 Compare
dstepanov-yadro dismissed acid-ant's review 2024-10-31 12:41:18 +00:00
Reason:

New commits pushed, approval review dismissed automatically according to repository settings

dstepanov-yadro force-pushed fix/deposit_vub from ce13b46281 to 2bcdb65378 2024-10-31 13:52:40 +00:00 Compare
dstepanov-yadro force-pushed fix/deposit_vub from 2bcdb65378 to 99240923a2 2024-10-31 13:53:00 +00:00 Compare
dstepanov-yadro force-pushed fix/deposit_vub from 99240923a2 to 1fd704a376 2024-10-31 14:10:37 +00:00 Compare
fyrchik commented 2024-10-31 14:18:58 +00:00
Owner
Copy link

on a side note: systemd status will update after we have made bootstrap request, right?

on a side note: systemd status will update after we have made bootstrap request, right?
dstepanov-yadro commented 2024-10-31 14:26:15 +00:00
Author
Member
Copy link

on a side note: systemd status will update after we have made bootstrap request, right?

yes

> on a side note: systemd status will update after we have made bootstrap request, right? yes
fyrchik reviewed 2024-11-01 11:04:05 +00:00
cmd/frostfs-node/morph.go Outdated
@ -197,0 +201,4 @@
}
return fmt.Errorf("could not wait for notary deposit persists in chain: %w", err)
}
if success := res.Execution.VMState.HasFlag(vmstate.Halt); success {
fyrchik commented 2024-11-01 11:04:05 +00:00
Owner
Copy link

if res.Execution.VMState.HasFlag(vmstate.Halt) {?

`if res.Execution.VMState.HasFlag(vmstate.Halt) {`?
dstepanov-yadro commented 2024-11-01 13:42:35 +00:00
Author
Member
Copy link

ok, fixed

ok, fixed
dstepanov-yadro force-pushed fix/deposit_vub from 1fd704a376 to 6c45a17af6 2024-11-01 13:42:25 +00:00 Compare
fyrchik merged commit 6c45a17af6 into master 2024-11-05 13:05:55 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
TrueCloudLab/storage-core-developers
Labels
Clear labels   
P0

Highest

  
P1

High

  
P2

Medium

  
P3

Low

  
badger

Badger DB related issues

  
frostfs-adm

   
frostfs-cli

   
frostfs-ir

   
frostfs-lens

   
frostfs-node

   
good first issue

Good for newcomers

  
triage
  
Infrastructure

Infrastructure, Automation, CI/CD or DevOps related stuff

  
blocked

The issue or PR is blocked by something

  
bug

Something is not working

  
config

Configuration format update or breaking change

  
discussion

Talking about something in order to reach a decision or to exchange ideas

  
documentation

Documentation related

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
go

Language features adoption

  
help wanted

Extra attention is needed

  
internal

   
invalid

Something is wrong

  
kludge

This is a kludge and we know it

  
observability

Related to metrics, tracing and logs

  
perfomance

Perfomance related

  
question

More information is needed

  
refactoring

Refactoring

  
wontfix

This won't be fixed

No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-node#1467
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:fix/deposit_vub"

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?