harrystech/rails-pipeline — pull request #8 by akeem (2014-10-30 16:42:09+00:00)
Title: A patch to find compatible handler

Before this change, when a 1_0 message is registered with a handler and/or
target class and a more recent minor version, 1_1, arrives at the subscriber:

- 1_1 may not be in the subscriber's namespace because it doesn't yet have
an updated set of schemas. Result: subscriber drops a message it can
parse and process.

- The subscriber has an updated set of schemas, but 1_1 is not registered
with a custom handler. It can't find a custom handler for 1_1. Result:
subscriber drops a message it can parse and process.

Here are the primary implications of this change:

- A 1_1 message written to the wire will now be handled by the 1_0
message and the associated handler explicitly registered in a
subscribing application. This will happen even if the 1_1 class isn't
in the subscribing application's namespace.

- If the subscriber application wants to begin using changes in 1_1,
then it has to explicitly register a handler against 1_1 instead of
1_0. This prevents a message-parsing-compatible change to the schema
from being processed by a handler that hasn't been built to handle
the change in backwards-compatible way.

- We will *always* parse a later minor version with the minor version
registered within the subscriber application. This is possible
as long as we use Protocol Buffer schema evolution rules here:
https://developers.google.com/protocol-buffers/docs/proto#updating.
The registered minor version is the object that will be passed
to its associated registered handler.

When a message comes in we now do the following:

1) We find a compatible, explicitly registered message type (e.g. the
same base type on the same major version)
2) Use that type to both parse the payload and pass to its registered
handler.