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

Remove legacy error downcasting from miner actor #1322

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

anorth
Copy link
Member

@anorth anorth commented Jun 27, 2023

Replaces a swathe of verbose and opaque error conversion with ActorErrors. The general pattern is to always return an ActorError from the state objects, needing minimal context or conversion in the actor code. This is almost all mechanical.

This hasn't purged anyhow entirely from the miner actor, it's still used in some utility modules.

There'll be more of these (smaller) to come. @Stebalien if you review this one, I'll send future iterations on the same pattern only to @alexytsu

See #52.

@anorth anorth requested review from Stebalien and alexytsu June 27, 2023 23:03
Copy link
Member

@Stebalien Stebalien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm generally in favor of this. We'll lose a little bit of information as implemented, but that likely doesn't matter.


self.add_expiration_partitions(
store,
fault_expiration_epoch,
&partitions_with_fault,
quant,
)
.map_err(|e| {
e.downcast_default(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: this means:

  1. If anything inside here specified an actor error, we'll lose it.
  2. We won't keep, e.g., serialization errors.

However... honestly, I think that's fine. I'd actually like to move away from "serialization" errors and stick to "illegal state" and "illegal argument" errors.

@anorth
Copy link
Member Author

anorth commented Jul 2, 2023

@Stebalien thanks for reviewing this. I may have been a bit premature. There are some other cases of lost information, but I was trying not to do that.

I will write up an issue with more detail on the challenges.

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.

2 participants