anchor.diff:  Cloud Pub/Sub will attempt redelivery according to subscription `ackDeadline` setting and the `max-ack-extension-period` client library setting.
   
   {empty}** For the adapter, "success" means the Spring Integration flow processed without raising an exception, so successful message processing and the successful completion of an error handler both result in the same behavior (message will be acknowledged).
  -To trigger default error behavior (nacking in `AUTO` mode; neither acking nor nacking in `AUTO_ACK` mode), propagate the error back to the adapter by throwing an exception from the error handler.
  -
  -===== Manual acking/nacking
  +To trigger default error behavior (nacking in `AUTO` mode; neither acking nor nacking in `AUTO_ACK` mode), propagate the error back to the adapter by throwing an exception from the <<Error Handling,Error Handling flow>>.
  +
  +====== Manual acking/nacking
   
   The adapter attaches a `BasicAcknowledgeablePubsubMessage` object to the `Message` headers.
   Users can extract the `BasicAcknowledgeablePubsubMessage` using the `GcpPubSubHeaders.ORIGINAL_MESSAGE` key and use it to ack (or nack) a message.
  
positive.code: 	    .getHeaders().get(GcpPubSubHeaders.ORIGINAL_MESSAGE);
  
  	originalMessage.nack();
  
      // retrow to let the adapter know something went wrong.
      // this will prevent the message from being automatically acknowledged.
      throw message.getPayload();
  }
  ----
  
  
negative.code: While `PubSubInboundChannelAdapter`, through the underlying Asynchronous Pull Pub/Sub mechanism, provides the best performance for high-volume applications that receive a steady flow of messages, it can create load balancing anomalies due to message caching.
  This behavior is most obvious when publishing a large batch of small messages that take a long time to process individually.
  It manifests as one subscriber taking up most messages, even if multiple subscribers are available to take on the work.
  For a more detailed explanation of this scenario, see https://cloud.google.com/pubsub/docs/pull#streamingpull_dealing_with_large_backlogs_of_small_messages[GCP Pub/Sub documentation].
  
  In such a scenario, a `PubSubMessageSource` can help spread the load between different subscribers more evenly.
  
  