When consuming events, determine the correct signal to use from the message header rather than an argument passed into the management command. This is a necessary step towards allowing multiple event types on a single topic.
Temporarily makes the signal argument optional so it can be safely removed from callers without needing a lockstep upgrade. After we are reasonably certain we have upgraded any processes using the management command, we can make the breaking change and do a major version upgrade.
Also, since Consumer.poll() may return a message with an error object, remove misleading documentation saying it can't. DeserializingConsumer turned those errors into exceptions but the plain Consumer will keep them as errors on the message.
Issue: https://github.com/openedx/openedx-events/issues/78
When consuming events, determine the correct signal to use from the message header rather than an argument passed into the management command. This is a necessary step towards allowing multiple event types on a single topic. Temporarily makes the
signalargument optional so it can be safely removed from callers without needing a lockstep upgrade. After we are reasonably certain we have upgraded any processes using the management command, we can make the breaking change and do a major version upgrade.Also, since Consumer.poll() may return a message with an error object, remove misleading documentation saying it can't. DeserializingConsumer turned those errors into exceptions but the plain Consumer will keep them as errors on the message.