Why is payload_too_large? and the actual size of the payload not public?

[mbillard]

We currently try to truncate the alert when exceeding the payload dimension, but without actual numbers it's kind of difficult.

We're left with 2 options:

• fork and expose payload_too_large? and a new payload_size (which is encoded_payload.bytesize)
• use send to access private methods

I wanted to know if there was any reason for making these private. If not, then you can expect a PR promptly.

Thanks

[stevenharman]

A similar topic was brought up not too long ago in #78, but it was determined it we didn't need to expose the actual #encoded_payload. In your case, I can understand to expose the #payload_size while keeping the actual encoded payload an implementation detail.

An alternative idea: What if we enhance the #validate_payload to raise a PayloadTooLargeError error which has more details about the exact size. So you could directly use that if you wanted. And we could go a step further and also have the #valid? method shove the rescued exception's #message into an array of errors, which we expose via a #errors method. Thoughts?

[mbillard]

I'd rather avoid using exceptions for flow control. If there's no particular reason for hiding these methods, I would simply expose them.

Not exposing encoded_payload is fine though.

Using #errors could also work, but it seems like too much trouble and indirect.

[stevenharman]

I'd rather avoid using exceptions for flow control.

I agree completely, which is why Grocer would expose a #valid? method for you to use. Internally we'd leverage exceptions, but we're not switching behavior based on them. And internally we do consider a notification with too large a body to be the exceptional case, rather than the expected case. But again, from the consumer's (i.e., your code's) perspective, it's just a predicate method, as per usual. ;)

I was thinking the #valid? + #errors would be nice b/c it would prevent consumers from having to know all of the various ways that something might be invalid. (e.g., no payload, payload too large, etc.)

[n-studio]

+1 for #valid? and #errors, but how do you get the bytesize from #errors?

[mbillard]

@n-studio I simply made payload_size public

[stevenharman]

@n-studio My thinking is: as part of the enhancement to #valid? and exposing #errors, we'd put the current encoded_payload.bytesize into the error message we give to PayloadTooLargeError. Does that make sense?

[stevenharman]

@mbillard I do still think going with #valid and #errors to be a great option for handling this, but I don't have the need for it now. However, you do need to know that information. If you're up for submitting your changes as a PR, I think we can merge them.

Thoughts?

[n-studio]

@mbillard Yes, I think it's necessary to have payload_size public.

@stevenharman If encoded_payload.bytesize is only in the error message then we need to parse the message to get the size, which would be ugly.
But if payload_size is public, everything is great!