Skip to content

Conversation

@bema-aei
Copy link
Contributor

  • The assimilator may have already started to assimilate this WU. The validator may take quite some time to chew through a chunk of workunits. Resetting the assimilate_state after that may be harmful and override the update made by the assimilator. Instead, let the transitioner decide what to do with this workunit.

  • Also too, avoid overriding a non-zero error mask that might have been set in the meantime by some other daemon

Fixes #5706

- The assimilator may have already started to assimilate this WU.
  The validator may take quite some time to chew through a chunk of workunits.
  Resetting the assimilate_state after that may be harmful and override the
  update made by the assimilator.
  Instead, let the transitioner decide what to do with this workunit.

- Also too, avoid overriding a non-zero error mask
@bema-aei bema-aei marked this pull request as draft July 24, 2024 14:21
@brevilo
Copy link
Contributor

brevilo commented Jul 24, 2024

Crappy GitHub doesn't let me comment outside a hunk's context. I presume this comment needs to be removed as they contradict the new logic (and comment), I think.

@bema-aei
Copy link
Contributor Author

bema-aei commented Jul 24, 2024

Right. And I think this loop should be deleted as well, as this should be done by the transitioner then anyway.

@bema-aei
Copy link
Contributor Author

I'm afraid the current transitioner relies on the validator setting assimilate_state as a sign of finished validation, at least under certain conditions. I need to think about this a little more.

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.

Server: validator - assimilator race condition - should validator set assimilate_state?

2 participants