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

Don't delegate to bulkhead, it might be nil #143

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

dalehamel
Copy link
Member

@dalehamel dalehamel commented Apr 3, 2017

What

Prevent a nil pointer dereference if attempting to read the name (or any other attribute delegated to bulkhead) of a protected resource without a bulkhead.

Why

Since bulkheads are now optional, we shouldn't delegate anything explicitly to them, as this can result in a nil pointer dereference.

How

The name is attempted to be read from the bulkhead first, falling back to the circuit breaker. If neither works, it will be nil, but it won't cause an exception to be raised from a nil pointer dereference.

Every other attribute has a safe accessor method defined, which will return a default value (same as for an unprotected resource) if there is no bulkhead.

@dalehamel dalehamel requested review from BoGs and sirupsen April 3, 2017 16:05
@dalehamel dalehamel changed the title Must be able to access name without a bulkhead Don't delegate to bulkhead, it might be nil Apr 3, 2017
@dalehamel
Copy link
Member Author

We might just want "allow_nil" here, not sure what the best behavior is.

Copy link
Contributor

@sirupsen sirupsen left a comment

Choose a reason for hiding this comment

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

Yeah, I think we should consider just doing allow_nil. This is definitely an error, I don't think we should mock every call.

@@ -2,15 +2,15 @@ module Semian
class ProtectedResource
extend Forwardable

def_delegators :@bulkhead, :destroy, :count, :semid, :tickets, :registered_workers, :name
def_delegators :@circuit_breaker, :reset, :mark_failed, :mark_success, :request_allowed?,
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we do the same if the circuit breaker is disabled?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah i think both should just do allow_nil.

@dalehamel
Copy link
Member Author

Yeah, I think we should consider just doing allow_nil. This is definitely an error, I don't think we should mock every call.

@sirupsen looks like allow_nil is a rails thing, if we are just using forwardable we might need to manually delegate things to make them safe when the delegate is nil.

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

3 participants