Skip to content

Return multiple errors from Writer.WriteMessages and MessageTooLargeError handling improvements #401

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

Closed
wants to merge 18 commits into from

Conversation

Evanjt1
Copy link

@Evanjt1 Evanjt1 commented Feb 11, 2020

Addresses issues #363 and #364

This PR revolves around 2 main improvements for the Writer type:

  • Return information about all errors that occurred during a write of multiple messages while still preserving interface of Writer.WriteMessages
  • Try to send all acceptable messages in a batch before returning the ones that are too large

I introduced two new public types, WriterError and WriterErrors to implement the first improvement. Both implement the error interface. Under the hood Writer.WriteMessages returns WriterErrors. The caller can cast the error returned as WriterErrors to use the new functionality if they so choose.

The second improvement is addressed by skipping messages that are too large as the Writer comes across them while sending to the msgs channel. They are instead stored as errors that will be returned after all the other messages have been tried.

New tests have been added to writer_test.go to ensure these features behave as expected. Additionally, some of the preexisting tests have been updated so they also check the WriterErrors returned.

There would have been a bunch of merge conflicts and wasted work if I tried to made both improvements individually so I decided to knock out two birds with one stone.

Add id field so that a given message can be tracked back to its index
when it was originally sent from Writer.WriteMessages. id allows
WriteMessages to keep track of which messages have been successfully
sent therefore making it easier to do more sophisticated error handling.
Change res channel type in writerMessage to new writerResponse struct
type so ids can be returned back to writer.WriteMessages. Refactor
affected receivers.
Implement WriterErrors type which implements the error interface to
allow for the returning of multiple WriterErrors that may occur during
a write. Provide basic Error() method which takes inspiration from
https://github.com/hashicorp/go-multierror/blob/72917a1559e17f38638ade54020ab372ba848d67/format.go#L14
so the slice of WriterError is formatted in a nice fashion.
error is a bit too general for dependent code. All err values are
WriterError anyway so make it the more specific type.
… before returning MessageTooLarge errors

Utilize WriterErrors and WriterError types to return all errors that
occur when sending a batch of messages using Writer.WriteMessages while
still preserving error return type. Try to send all eligible messages
in msgs before returning any MessageTooLarge errors.
@Evanjt1 Evanjt1 changed the title Multiple errors returned from Writer.WriteMessages and MessageTooLargeError handling improvements Return multiple errors from Writer.WriteMessages and MessageTooLargeError handling improvements Feb 11, 2020
@achille-roussel achille-roussel self-assigned this Feb 15, 2020
type WriterError struct {
Msg Message
Err error
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we have the WriterError and WriterErrors type implement errors.Wrapper?

Copy link
Author

@Evanjt1 Evanjt1 Feb 24, 2020

Choose a reason for hiding this comment

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

Will do, Unwrap() is straightforward for WriterError. Do you have thoughts on behavior for WriterErrors?

Copy link
Author

Choose a reason for hiding this comment

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

Unwrap needs to be implemented in order to use the Unwrap function
added in go 1.13.
@Evanjt1
Copy link
Author

Evanjt1 commented Dec 4, 2020

@achille-roussel This PR is pretty out-of-date at this point and your work on #438 covers the issues this PR was about so I think this should probably be closed.

@achille-roussel
Copy link
Contributor

Thanks for follow up @Evanjt1, I'll go ahead and close. Feel free to reopen an issue if the problem isn't properly addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants