Skip to content

power-policy-service: Depanic#634

Merged
RobertZ2011 merged 1 commit intoOpenDevicePartnership:mainfrom
RobertZ2011:power-policy-depanic
Dec 12, 2025
Merged

power-policy-service: Depanic#634
RobertZ2011 merged 1 commit intoOpenDevicePartnership:mainfrom
RobertZ2011:power-policy-depanic

Conversation

@RobertZ2011
Copy link
Contributor

No description provided.

@RobertZ2011 RobertZ2011 self-assigned this Dec 10, 2025
Copilot AI review requested due to automatic review settings December 10, 2025 23:13
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR removes panic-prone code patterns from the power-policy-service by replacing .expect() and .unwrap() calls with proper error handling. The changes improve the service's robustness by gracefully handling initialization failures and option unwrapping instead of potentially panicking at runtime.

Key changes:

  • Replaced .expect() with proper None handling in PowerPolicy initialization
  • Refactored .unwrap() usage by restructuring control flow to use if-let pattern for best_consumer

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
power-policy-service/src/lib.rs Replaced .expect() on PowerPolicy::create with if-let pattern and early return on None
power-policy-service/src/consumer.rs Replaced .unwrap() on best_consumer with if-let pattern, eliminating early return and simplifying control flow

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@RobertZ2011 RobertZ2011 marked this pull request as ready for review December 10, 2025 23:18
@RobertZ2011 RobertZ2011 requested review from a team as code owners December 10, 2025 23:18
@RobertZ2011 RobertZ2011 enabled auto-merge (squash) December 10, 2025 23:22
kurtjd
kurtjd previously approved these changes Dec 10, 2025
@RobertZ2011 RobertZ2011 requested a review from a team as a code owner December 11, 2025 23:38
Copilot AI review requested due to automatic review settings December 11, 2025 23:53
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 2 out of 8 changed files in this pull request and generated no new comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@RobertZ2011 RobertZ2011 requested a review from kurtjd December 12, 2025 16:40
kurtjd
kurtjd previously approved these changes Dec 12, 2025
felipebalbi
felipebalbi previously approved these changes Dec 12, 2025
asasine
asasine previously approved these changes Dec 12, 2025
Copy link
Contributor

@asasine asasine left a comment

Choose a reason for hiding this comment

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

non-blocking

@RobertZ2011 RobertZ2011 dismissed stale reviews from asasine, felipebalbi, and kurtjd via 0811e05 December 12, 2025 22:23
@RobertZ2011 RobertZ2011 merged commit 555e20a into OpenDevicePartnership:main Dec 12, 2025
14 checks passed
@jerrysxie jerrysxie added the enhancement New feature or request label Dec 12, 2025
jerrysxie pushed a commit that referenced this pull request Dec 24, 2025
Removed panic paths from the `buffer` module. Instead made methods
fallible and introduced an `Error` type.

Because certain traits are used with methods that assume infallibility
(such as the drop and borrow traits), I couldn't just make these return
a result. Instead, I added a `Poisoned` status so in the off chance that
a `drop` or `borrow` call would have panicked originally, the buffer is
marked poisoned and will return a `Poisoned` error on future accesses.

This also breaks the interfaces of a few services. For these I added a
`Buffer` error and made methods fallible if necessary. I'm not a fan of
this since any buffer errors represent an internal programming bug to
the service and not something the user should expect/handle, and this
breaks encapsulation. I do not want to silently just ignore buffer
errors, so I'm not sure what other alternative there is here (open to
suggestions).

*Edit*: Thinking about maybe renaming the `Buffer` error variant of
these services to `Internal` or something. I'd prefer to make it more
clear when an error represents an internal invariant being broken that
is not something meant to be handled by the caller in any practical
manner. It would act as a catchall since the specifics of what caused
the error are implementation details that could change any time and not
something the caller should be concerned with.

Also introduced a `Never` type alias which is useful now that some
functions represent never-ending tasks which should never return unless
there is an error (see related discussion:
#634 (comment)).

Resolves #659
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

6 participants