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

Backport of handle FSM.Apply errors in raftApply into release/1.4.x #16302

Merged
merged 1 commit into from
Mar 2, 2023

Conversation

hc-github-team-nomad-core
Copy link
Contributor

Backport

This PR is auto-generated from #16287 to be assessed for backporting due to the inclusion of the label backport/1.4.x.

WARNING automatic cherry-pick of commits failed. Commits will require human attention.

The below text is copied from the body of the original PR.


The signature of the raftApply function requires that the caller unwrap the first returned value (the response from FSM.Apply) to see if it's an error. This puts the burden on the caller to remember to check two different places for errors, and we've done so inconsistently.

Update raftApply to do the unwrapping for us and return any FSM.Apply error as the error value. Similar work was done in Consul in hashicorp/consul#9991. This eliminates some boilerplate and surfaces a few minor bugs in the process:

  • job deregistrations of already-GC'd jobs were still emitting evals
  • reconcile job summaries does not return scheduler errors
  • node updates did not report errors associated with inconsistent service discovery or CSI plugin states

Note that although most of the FSM.Apply functions return only errors (which makes it tempting to remove the first return value entirely), there are few that return bool for some reason and Variables relies on the response value for proper CAS checking.

@hc-github-team-nomad-core hc-github-team-nomad-core force-pushed the backport/fsm-errors/promptly-golden-rooster branch 2 times, most recently from 4cdef25 to bc0e4d0 Compare March 2, 2023 18:51
The signature of the `raftApply` function requires that the caller unwrap the
first returned value (the response from `FSM.Apply`) to see if it's an
error. This puts the burden on the caller to remember to check two different
places for errors, and we've done so inconsistently.

Update `raftApply` to do the unwrapping for us and return any `FSM.Apply` error
as the error value. Similar work was done in Consul in
hashicorp/consul#9991. This eliminates some boilerplate
and surfaces a few minor bugs in the process:

* job deregistrations of already-GC'd jobs were still emitting evals
* reconcile job summaries does not return scheduler errors
* node updates did not report errors associated with inconsistent service
  discovery or CSI plugin states

Note that although _most_ of the `FSM.Apply` functions return only errors (which
makes it tempting to remove the first return value entirely), there are few that
return `bool` for some reason and Variables relies on the response value for
proper CAS checking.
@tgross tgross force-pushed the backport/fsm-errors/promptly-golden-rooster branch from bc0e4d0 to 08b8394 Compare March 2, 2023 18:54
@tgross tgross merged commit e9aba9c into release/1.4.x Mar 2, 2023
@tgross tgross deleted the backport/fsm-errors/promptly-golden-rooster branch March 2, 2023 19:11
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.

None yet

2 participants