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

chore: release v0.5.1 #82

Closed
wants to merge 6 commits into from
Closed

chore: release v0.5.1 #82

wants to merge 6 commits into from

Conversation

RafilxTenfen
Copy link
Contributor

No description provided.

Lazar955 and others added 6 commits September 25, 2024 13:08
Run e2e tests with babylond in docker container.

Seems that in order to execute tests with `t.Parallel()` we will need to
do some refactoring in eots manager. Will be done in next PR.
Ensures that our e2e tests version use a correct version of babylond
from go.mod
In the previous implementation, once a finality provider is jailed, when
the fpd is restarted, it will panic due to error from Babylon when fast
sync. This PR fixed this issue with the following changes:
1. We implemented `unjail` finality provider CLI other than using the
one from Babylon. This implementation will set the fp instance status to
`inactive` after `unjail` tx is successfully sent (will later updated to
active if the fp has voting power).
2. Once `jailed` error is detected while starting a fp instance, it will
fail but the fpd will not panic, meaning that the loop for updating
stored fp status continues running.

Now the flow of jailing/unjailing becomes the follows:
1. fpd detects jailing via err when sending a fp sig or a loop for
checking fp status
2. once `jailed` detected, fpd terminates the fp instance without
terminating the program
3. the operator checks fp signing info to get the `jail_until` via
`babylond q finality signing-info [fp-pk-hex]`
4. after the `jail_until` is passed, the operator can unjail the fp by
executing `fpd unjail-finality-provider [fp-pk-hex]`
5. if everything goes well, the fp will continue sending finality votes
if it has voting power after a period of waiting for state transition
New release `v0.5.x` should be created after this PR
@RafilxTenfen
Copy link
Contributor Author

Hey @gitferry running the local deployments with this version, the finality provider is stopping after being slashed, is this expected?

2024-10-02T19:57:56.755449Z	debug	failed to submit finality signature to the consumer chain	{"pk": "b35a9a5fcc681f38f404bb4bc181e96853739db1df8c72c3a764990b5bc886dd", "current_failures": 0, "target_block_height": 45, "error": "failed to send finality signature to the consumer chain: the finality provider has already been slashed"}
2024-10-02T19:57:56.755495Z	fatal	terminating the finality-provider instance due to critical error	{"pk": "b35a9a5fcc681f38f404bb4bc181e96853739db1df8c72c3a764990b5bc886dd", "error": "failed to send finality signature to the consumer chain: the finality provider has already been slashed"}

@RafilxTenfen
Copy link
Contributor Author

New release v06 will be done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants