Learn Pub/Sub Architecture in RabbitMQ: Nack Requeue

Logical errors: Unlikely to be resolved with a retry. For example, a message is malformed JSON, or the ID of a user doesn't exist in the database.
Transient errors: Likely to be resolved with a retry. For example, a network timeout, or a database connection error.

Update the "move" handler so that when detects MoveOutcomeMakeWar, it should:

Publish a message to the "topic" exchange with the routing key $WARPREFIX.$USERNAME. routing.WarRecognitionsPrefix contains the $WARPREFIX constant, and the $USERNAME should be the name of the player consuming the move.
NackRequeue the message... Might seem crazy, but it will be fun.

Create a new handler that consumes all the war messages that the "move" handler publishes, no matter the username in the routing key. It should:

defer fmt.Print("> ") to ensure a new prompt is printed after the handler is done.
Call the gamestate's HandleWar method with the message's body.
If the outcome is gamelogic.WarOutcomeNotInvolved: NackRequeue the message so another client can try to consume it.
If the outcome is gamelogic.WarOutcomeNoUnits: NackDiscard the message.
If the outcome is gamelogic.WarOutcomeOpponentWon: Ack the message.
If the outcome is gamelogic.WarOutcomeYouWon: Ack the message.
If the outcome is gamelogic.WarOutcomeDraw: Ack the message.
If it's anything else, print an error and NackDiscard the message.

Use a durable queue with the war handler. The queue name should just be war. All clients will share this queue. Whenever war is declared, only one client will consume the message.

Test the changes.

Open the war queue in your rabbitmq management UI.
Have washington spawn a unit: spawn americas infantry
Have napoleon spawn a unit: spawn europe cavalry
Have washington move into napoleon's territory: move europe 1

Nack Requeue

Assignment