pub_sub_model_sync 0.5.10 → 0.6.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c3cb9b467f173cf208d051aead1d069868b9dfd6cc319311aac4fdaa3431d05f
-  data.tar.gz: b5f6dad938ee545ab4f99c6cd51b84e574856c63f044f5a46e784ca17a01076c
+  metadata.gz: c5b72a2c8c7d97a09c17b3985ce466ecf1fba62573dbb860fae9ccab064e84d9
+  data.tar.gz: 4f0f801bc9d51fee36b5f279c4f995d9bf441f608ea26d16314dd2182bf67dc7
 SHA512:
-  metadata.gz: c548cd499bfde36a4d0db4a8dc75e8ad3cadc389cfffb55c95db9ab306ecc7ce338274603e66ebb1f45932fd1de61cc5f6d4ad123c6ed0931ad3284cbdc957f3
-  data.tar.gz: 62ced05bba4175c69d4453e35f5c9fa3414b1d2f123d40ada555e75bc876488d78f388e87a20a01c1bf895ab2991eeb1a0f2287cbd593aaec8d0429aec7519ee
+  metadata.gz: bdb68283d5feca9b506a11478671e8deea6e425065ececefd2162a227b01a7be837fdd533fd5b51e58e60e3d438ffa8e89009f690e0b68696b06cc6e204f5c24
+  data.tar.gz: 99baadbbd02b889af06b4cd1b17847a61efe074d58c3f7cc6b0e3eb693f277604f5420b8924bca383cfc8cdbba550d8c16755231335e0a1e056663cb0a5f4deb

data/.github/workflows/ruby.yml

@@ -24,7 +24,7 @@ jobs:
     steps:
       - uses: actions/checkout@v2
       - name: Set up Ruby
-        uses: actions/setup-ruby@v1
+        uses: ruby/setup-ruby@v1
         with:
           ruby-version: ${{ matrix.ruby }}
       - name: Install sqlite3

data/CHANGELOG.md

@@ -1,5 +1,18 @@
 # Change Log
 
+# 0.6.0 (March 03, 2021)
+- feat: add support to include custom payload headers
+- feat: add pubsub transactions to process all payloads inside in the same order they were published
+- feat: when a model is created/updated/destroyed, process all related payloads in a single transaction
+- feat: add method to save processed payload (:ps_processed_payload) when saving sync
+- feat: add "ordering_key" support to process all payloads with the same key in the same order
+- feat: start multiple workers to process async kafka messages when starting service listeners
+- feat: make async publisher by reusing exchange connection (rabbit)
+- feat: add support for forced_ordering_key to always be used as the ordering_key if defined
+- feat: add feature to publish a message to a custom and/or multiple topics 
+- feat: add model custom action subscriber and publisher
+- feat: add docker compose settings
+
 # 0.5.10 (February 13, 2021)
 - feat: remove duplicated callback :ps_before_save_sync (same result can be achieved with :ps_before_save_sync)
 - feat: improve message starter to retry when failed or exit system when persists

data/Dockerfile

@@ -0,0 +1,6 @@
+FROM ruby:2.7-buster
+RUN apt-get update -qq
+WORKDIR /myapp
+COPY . /myapp
+RUN gem update bundler
+RUN bundle install

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    pub_sub_model_sync (0.5.10)
+    pub_sub_model_sync (0.6.0)
       rails
 
 GEM
@@ -243,6 +243,7 @@ DEPENDENCIES
   database_cleaner-active_record
   google-cloud-pubsub (> 2.0)
   pub_sub_model_sync!
+  rails (~> 6)
   rake
   rspec
   rubocop (~> 1.6.0)

data/README.md

@@ -6,8 +6,9 @@ Note: This gem is based on [MultipleMan](https://github.com/influitive/multiple_
 - [**PubSubModelSync**](#pubsubmodelsync)
   - [**Features**](#features)
   - [**Installation**](#installation)
-  - [**Usage**](#usage)
-  - [**Examples**](#examples)
+  - [**Configuration**](#configuration)
+  - [**Notifications Diagram**](#notifications-diagram)
+  - [**Basic Example**](#basic-example)
   - [**Advanced Example**](#advanced-example)
   - [**API**](#api)
     - [**Subscribers**](#subscribers)
@@ -33,6 +34,10 @@ Note: This gem is based on [MultipleMan](https://github.com/influitive/multiple_
 - Ability to make class level communication
     Example: If User from App1 wants to generate_email, this can be listened on App2, App3, ... to make corresponding actions
 - Change pub/sub service at any time
+- Support for transactions: Permits to group all payloads with the same ordering_key and be processed in the same order they are published by the subscribers. 
+  Grouping by ordering_key allows us to enable multiple workers in our Pub/Sub service(s), and still guarantee that related payloads will be processed in the correct order, despite of the multiple threads. 
+  This thanks to the fact that Pub/Sub services will always send messages with the same `ordering_key` into the same worker/thread.
+- Ability to send notifications to a specific topic or multiple topics
 
 ## **Installation**
 Add this line to your application's Gemfile:
@@ -46,7 +51,7 @@ gem 'ruby-kafka' # to use apache kafka pub/sub service
 And then execute: $ bundle install
 
 
-## **Usage**
+## **Configuration**
 
 - Configuration for google pub/sub (You need google pub/sub service account)
     ```ruby
@@ -54,7 +59,8 @@ And then execute: $ bundle install
     PubSubModelSync::Config.service_name = :google
     PubSubModelSync::Config.project = 'google-project-id'
     PubSubModelSync::Config.credentials = 'path-to-the-config'
-    PubSubModelSync::Config.topic_name = 'sample-topic'
+    PubSubModelSync::Config.topic_name = 'sample-topic' 
+    PubSubModelSync::Config.subscription_name = 'my-app1'
     ```
     See details here:
     https://github.com/googleapis/google-cloud-ruby/tree/master/google-cloud-pubsub
@@ -63,8 +69,8 @@ And then execute: $ bundle install
     ```ruby
     PubSubModelSync::Config.service_name = :rabbitmq
     PubSubModelSync::Config.bunny_connection = 'amqp://guest:guest@localhost'
-    PubSubModelSync::Config.queue_name = 'model-sync'
     PubSubModelSync::Config.topic_name = 'sample-topic'
+    PubSubModelSync::Config.subscription_name = 'my-app2'
     ```
     See details here: https://github.com/ruby-amqp/bunny
 
@@ -73,27 +79,25 @@ And then execute: $ bundle install
     PubSubModelSync::Config.service_name = :kafka
     PubSubModelSync::Config.kafka_connection = [["kafka1:9092", "localhost:2121"], { logger: Rails.logger }]
     PubSubModelSync::Config.topic_name = 'sample-topic'
+    PubSubModelSync::Config.subscription_name = 'my-app3'
     ```
     See details here: https://github.com/zendesk/ruby-kafka
 
 - Add publishers/subscribers to your models (See examples below)
 
 - Start subscribers to listen for publishers (Only in the app that has subscribers)
-    ```ruby
-    rake pub_sub_model_sync:start
-    ```
-    Note: Publishers do not need todo this
-    Note2 (Rails 6+): Due to Zeitwerk, you need to load listeners manually when syncing without mentioned task (like rails console)
-    ```ruby
-      # PubSubModelSync::Config.subscribers ==> []
-      PubSubModelSync::Runner.preload_listeners
-      # PubSubModelSync::Config.subscribers ==> [#<PubSubModelSync::Subscriber:0x000.. @klass="Article", @action=:create..., ....]
+    ```bash
+    DB_POOL=20 bundle exec rake pub_sub_model_sync:start
     ```
+    Note: You need more than 15 DB pools to avoid "could not obtain a connection from the pool within 5.000 seconds". https://devcenter.heroku.com/articles/concurrency-and-database-connections
 
 - Check the service status with:
   ```PubSubModelSync::MessagePublisher.publish_data('Test message', {sample_value: 10}, :create)```
 
-## **Examples**
+## **Notifications Diagram**
+![Diagram](/docs/notifications-diagram.png?raw=true)
+
+## **Basic Example**
 ```ruby
 # App 1 (Publisher)
 # attributes: name email age
@@ -105,20 +109,25 @@ end
 # App 2 (Subscriber)
 class User < ActiveRecord::Base
   include PubSubModelSync::SubscriberConcern
-  ps_subscribe(%i[name])
-  ps_class_subscribe(:greeting)
+  ps_subscribe(%i[name]) # crud notifications
+  ps_subscribe_custom(:say_welcome) # custom instance notification
+  ps_class_subscribe(:greeting) # class notification
 
   def self.greeting(data)
     puts 'Class message called'
   end
+  
+  def say_welcome(data)
+    UserMailer.deliver(id, data)
+  end
 end
 
 # Samples
 User.create(name: 'test user', email: 'sample@gmail.com') # Review your App 2 to see the created user (only name will be saved)
 User.new(name: 'test user').ps_perform_sync(:create) # similar to above to perform sync on demand
 
-User.ps_class_publish({ msg: 'Hello' }, action: :greeting) # User.greeting method (Class method) will be called in App2
-PubSubModelSync::MessagePublisher.publish_data(User, { msg: 'Hello' }, :greeting) # similar to above when not included publisher concern
+PubSubModelSync::MessagePublisher.publish_model_data(my_user, { id:10, msg: 'Hello' }, :say_welcome, { as_klass: 'RegisteredUser' }) # custom model action notification
+PubSubModelSync::MessagePublisher.publish_data(User, { msg: 'Hello' }, :greeting) # custom data notification
 ```
 
 ## **Advanced Example**
@@ -127,7 +136,7 @@ PubSubModelSync::MessagePublisher.publish_data(User, { msg: 'Hello' }, :greeting
 class User < ActiveRecord::Base
   self.table_name = 'publisher_users'
   include PubSubModelSync::PublisherConcern
-  ps_publish(%i[id:client_id name:full_name email], actions: %i[update], as_klass: 'Client')
+  ps_publish(%i[id:client_id name:full_name email], actions: %i[update], as_klass: 'Client', headers: { topic_name: ['topic1', 'topic N'] })
 
   def ps_skip_callback?(_action)
     false # here logic with action to skip push message
@@ -144,11 +153,16 @@ class User < ActiveRecord::Base
   include PubSubModelSync::SubscriberConcern
   ps_subscribe(%i[name], actions: %i[update], from_klass: 'Client', id: %i[client_id email])
   ps_class_subscribe(:greeting, from_action: :custom_greeting, from_klass: 'CustomUser')
+  ps_subscribe_custom(:send_welcome, from_klass: 'CustomUser', id: :id, from_action: :say_welcome)
   alias_attribute :full_name, :name
 
   def self.greeting(data)
     puts 'Class message called through custom_greeting'
   end
+  
+  def send_welcome(data)
+    UserMailer.deliver(id, data)
+  end
 
   # def self.ps_find_model(data)
   #   where(email: data[:email], ...).first_or_initialize
@@ -156,136 +170,207 @@ class User < ActiveRecord::Base
 end
 ```
 
-Note: Be careful with collision of names
-```
-  # ps_publish %i[name_data:name name:key] # key will be replaced with name_data
-  ps_publish %i[name_data:name key_data:key] # use alias to avoid collision
-```
-
 ## **API**
 ### **Subscribers**
 
-#### **Registering Subscription Callbacks**
+#### **Registering Subscriptions**
 
-- Configure model-level subscriptions
+- Configure class subscriptions
   ```ruby
   class MyModel < ActiveRecord::Base
     ps_class_subscribe(action_name, from_action: nil, from_klass: nil)
   end
   ```
-  * `from_action`: (Optional) Source method name
-  * `from_klass`: (Optional) Source class name
+  When Class receives the corresponding notification, `action` method will be called on the Class. Like: `User.action(data)`
+  * `action_name`: (String|Sym/Optional) Action name
+  * `from_klass`: (String/Optional) Source class name (Default `model.class.name`)
+  * `from_action`: (Sym/Optional) Source method name. Default `action`
 
-- Configure instance-level subscriptions (CRUD)
+- Configure CRUD subscriptions
   ```ruby
   class MyModel < ActiveRecord::Base
     ps_subscribe(attrs, from_klass: nil, actions: nil, id: nil)
   end
   ```
+  When model receives the corresponding notification, `action` method will be called on the model. Like: `model.destroy`
   * `attrs`: (Array/Required) Array of all attributes to be synced
-  * `from_klass`: (String/Optional) Source class name (Instead of the model class name, will use this value)
+  * `from_klass`: (String/Optional) Source class name (Default `model.class.name`)
   * `actions`: (Array/Optional, default: create/update/destroy) permit to customize action names
   * `id`: (Sym|Array/Optional, default: id) Attr identifier(s) to find the corresponding model
 
-- Configure a custom model finder
+- Configure custom model subscriptions
   ```ruby
   class MyModel < ActiveRecord::Base
-    ps_find_model(data)
+    ps_subscribe_custom(action, from_klass: name, id: :id, from_action: nil)
   end
   ```
-  * `data`: (Hash) Data received from sync
-  Must return an existent or a new model object
+  When model receives the corresponding notification, `action` method will be called on the model. Like: `model.action(data)`
+  * `action`: (String/Required) Action name
+  * `from_klass`: (String/Optional) Source class name (Default `model.class.name`)
+  * `from_action`: (Sym/Optional) Source method name. Default `action`
+  * `id`: (Sym|Array/Optional, default: id) Attr identifier(s) to find the corresponding model
 
-#### **Class Methods**
-- Configure CRUD subscription for the class
+- Perform custom actions before saving sync of the model (`:cancel` can be returned to skip sync)
   ```ruby
-  MyModel.ps_subscriber(action_name)
+  class MyModel < ActiveRecord::Base
+    def ps_before_save_sync(action, payload)
+      # puts payload.data[:id]
+    end
+  end
   ```
-  * `action_name` (default :create, :sym): can be :create, :update, :destroy
+  
+- Configure a custom model finder (optional)
+  ```ruby
+  class MyModel < ActiveRecord::Base
+    def ps_find_model(data)
+      where(custom_finder: data[:custom_value]).first_or_initialize
+    end
+  end
+  ```
+  * `data`: (Hash) Data received from sync
+  Must return an existent or a new model object
 
-- Inspect all configured subscribers
+#### **Subscription helpers**
+- Inspect all configured subscriptions
   ```ruby
   PubSubModelSync::Config.subscribers
   ```
-
-#### **Instance Methods**
-
-- Perform custom actions before saving sync of the model (On-demand, `:cancel` can be returned to skip sync)
+- Manually process or reprocess a notification
   ```ruby
-  my_instance.ps_before_save_sync(payload)
+  payload = PubSubModelSync::Payload.new(data, attributes, headers)
+  payload.process!
   ```
 
+
 ### **Publishers**
 
-#### **Registering Publishing Callbacks**
-- You can register Model-level lifecycle callbacks (CRUD) that will trigger publishing events like this:
+#### **Registering Publishers **
+- Register CRUD publishers that will trigger configured notifications
   ```ruby
-  ps_publish(attrs, actions: nil, as_klass: nil)
+  class MyModel < ActiveRecord::Base
+    ps_publish([:id, 'created_at:published_at', :full_name], actions: [:update], as_klass: nil, headers: { ordering_key: 'custom-key', topic_name: 'my-custom-topic' })
+    def full_name
+      [first_name, last_name].join(' ')
+    end
+  end
   ```
-  * `attrs`: (Array/Required) Array of attributes to be published
-  * `actions`: (Array/Optional, default: create/update/destroy) permit to customize action names
+  * `attrs`: (Array/Required) Array of attributes to be published. Supports for:
+    - aliases: permits to publish with different names, sample: "created_at:published_at" where "created_at" will be published as "published_at" 
+    - methods: permits to publish method values as attributes, sample: "full_name"  
+  * `actions`: (Array/Optional, default: %i[create update destroy]) permit to define action names
   * `as_klass`: (String/Optional) Output class name (Instead of the model class name, will use this value)
+  * `headers`: (Hash/Optional) Notification settings which permit to customize the way and the target of the notification (Refer Payload.headers)
+  
 
+#### **Publishing notifications**
+- CRUD notifications
+  ```ruby 
+    MyModel.create!(...) 
+  ```    
+  "Create" notification will be delivered with the configured attributes as the payload data
 
-#### **Instance Methods**
+- Manual CRUD notifications
+  ```ruby
+  MyModel.ps_perform_sync(action, custom_data: {}, custom_headers: {})
+  ```
+  * `action`: (Sym) CRUD action name (create, update or destroy)
+  * `custom_data`: custom_data (nil|Hash) If present custom_data will be used as the payload data. I.E. data generator will be ignored
+  * `custom_headers`: (Hash, optional) override default headers. Refer `payload.headers`
+  
+- Class notifications
+  ```ruby 
+    PubSubModelSync::MessagePublisher.publish_data((klass, data, action, headers: )
+  ```
+  Publishes any data to be listened at a class level.
+  - `klass`: (String) Class name to be used
+  - `data`: (Hash) Data to be delivered
+  - `action`: (Sym) Action name
+  - `headers`: (Hash, optional) Notification settings (Refer Payload.headers)
+
+- Model custom action notifications
+  ```ruby 
+    PubSubModelSync::MessagePublisher.publish_model_data(model, data, action, as_klass:, headers:)
+  ```
+  Publishes model custom action to be listened at an instance level.
+  - `model`: (ActiveRecord) model owner of the data
+  - `data`: (Hash) Data to be delivered
+  - `action`: (Sym) Action name
+  - `as_klass`: (String, optional) if not provided, `model.class.name` will be used instead
+  - `headers`: (Hash, optional) Notification settings (Refer Payload.headers)
+  
+- Manually publish or republish a notification
+    ```ruby
+    payload = PubSubModelSync::Payload.new(data, attributes, headers)
+    payload.publish!
+    ```    
+
+#### ** publishing callbacks**
 
-- **Prevent PS-related callback** (On-demand, before the callback gets triggered)
+- Prevent CRUD sync at model callback level (Called right after :after_create, :after_update, :after_destroy). 
+  If returns "true", sync will be cancelled.
   ```ruby
-  model_instance.ps_skip_callback?(action)
+  class MyModel < ActiveRecord::Base
+    def ps_skip_callback?(action)
+      # logic here
+    end
+  end
   ```
-  Default: False
-  Note: Return true to cancel sync
 
--  **Prevent sync after create/update/destroy action** (On-demand, before the sync gets triggered)
+- Prevent CRUD sync before processing payload (Affects model.ps_perform_sync(...))).
+  If returns "true", sync will be cancelled
     ```ruby
-    model_instance.ps_skip_sync?(action)
+    class MyModel < ActiveRecord::Base
+      def ps_skip_sync?(action)
+        # logic here
+      end
+    end
     ```
-     Note: return true to cancel sync
 
-- **Execute a callback before sync** (On-demand, before sync is executed, but after payload is received )
+- Do some actions before publishing a CRUD notification.
+  If returns ":cancel", sync will be cancelled
   ```ruby
-  model_instance.ps_before_sync(action, data_to_deliver)
+      class MyModel < ActiveRecord::Base
+        def ps_before_sync(action, payload)
+          # logic here
+        end
+      end
   ```
-  Note: If the method returns ```:cancel```, the sync will be stopped (message will not be published)
 
-- **Execute a callback after sync**
+- Do some actions after CRUD notification was published.
   ```ruby
-  model_instance.ps_after_sync(action, data_delivered)
+    class MyModel < ActiveRecord::Base
+      def ps_after_sync(action, payload)
+        # logic here
+      end
+    end
   ```
 
-- **Trigger a sync on-demand** (:create, :update, :destroy):
-  The target model will receive a notification to perform the indicated action
-  ```ruby
-  model_instance.ps_perform_sync(action_name, custom_settings = {})
-  ```
-  * `custom_settings`: override default settings defined for action_name ({ attrs: [], as_klass: nil })
 
-#### **Class Methods**
+### **Payload**
+Any notification before delivering is transformed as a Payload for a better portability. 
 
-- **Publish a class level notification**:
+- Initialize  
   ```ruby
-  User.ps_class_publish(data, action: action_name, as_klass: custom_klass_name)
+    payload = PubSubModelSync::Payload.new(data, attributes, headers)
   ```
-  Target class ```User.action_name``` will be called when message is received
-  * `data`: (required, :hash) message value to deliver
-  * `action_name`: (required, :sim) Action name
-  * `as_klass`: (optional, :string) Custom class name (Default current model name)
-
-#### **Payload actions**
+  * `data`: (Hash) Data to be published or processed
+  * `attributes`: (Hash) Includes class and method info
+    - `action`: (String) action name
+    - `klass`: (String) class name
+  * `headers`: (Hash) Notification settings that defines how the notification will be processed or delivered. 
+    - `key`: (String, optional) identifier of the payload, default: `<klass_name>/<action>` when class message, `<model.class.name>/<action>/<model.id>` when model message (Useful for caching techniques).
+    - `ordering_key`: (String, optional): messages with the same key are processed in the same order they were delivered, default: `klass_name` when class message, `<model.class.name>/<model.id>` when model message
+    - `topic_name`: (String|Array<String>, optional): Specific topic name to be used when delivering the message (default first topic from config).
+    - `forced_ordering_key`: (String, optional): Will force to use this value as the `ordering_key`, even withing transactions. Default `nil`.
+  
+- Actions for payloads
   ```ruby
-    payload = PubSubModelSync::Payload.new({ title: 'hello' }, { action: :greeting, klass: 'User' })
     payload.publish! # publishes notification data. It raises exception if fails and does not call ```:on_error_publishing``` callback
     payload.publish # publishes notification data. On error does not raise exception but calls ```:on_error_publishing``` callback
     payload.process! # process a notification data. It raises exception if fails and does not call ```.on_error_processing``` callback
     payload.publish # process a notification data. It does not raise exception if fails but calls ```.on_error_processing``` callback
   ```
 
-- Get crud publisher configured for the class
-  ```ruby
-  User.ps_publisher(action_name)
-  ```
-  * `action_name` (default :create, :sym): can be :create, :update, :destroy
-
 ## **Testing with RSpec**
 - Config: (spec/rails_helper.rb)
     ```ruby
@@ -341,7 +426,7 @@ Note: Be careful with collision of names
       publisher = PubSubModelSync::MessagePublisher
       data = {msg: 'hello'}
       action = :greeting
-      User.ps_class_publish(data, action: action)
+      PubSubModelSync::MessagePublisher.publish_data('User', data, action)
       expect(publisher).to receive(:publish_data).with('User', data, action)
     end
     ```
@@ -351,9 +436,12 @@ Note: Be careful with collision of names
 config = PubSubModelSync::Config
 config.debug = true
 ```
-
-- ```.subscription_name = 'app-2'```
-    Permit to define a custom consumer identifier (Default: Rails application name)
+- `.topic_name = ['topic1', 'topic 2']`: (String|Array<String>)    
+    Topic name(s) to be used to listen all notifications from when listening. Additional first topic name is used as the default topic name when publishing a notification. 
+- `.subscription_name = "my-app-1"`:  (String, default Rails.application.name)     
+    Subscriber's identifier which helps to: 
+    * skip self messages
+    * continue the sync from the last synced notification when service was restarted.
 - ```.debug = true```
     (true/false*) => show advanced log messages
 - ```.logger = Rails.logger```
@@ -378,18 +466,15 @@ config.debug = true
 - Add flag ```model.ps_process_payload``` to retrieve the payload used to process the pub/sub sync
 - Auto publish update only if payload has changed
 - On delete, payload must only be composed by ids
-- Feature to publish multiple message at a time with the ability to exclude similar messages by klass and action (use the last one)
-    PubSubModelSync::MessagePublisher.batch_publish({ same_keys: :use_last_as_first|:use_last|:use_first_as_last|:keep*, same_data: :use_last_as_first*|:use_last|:use_first_as_last|:keep })
-- Add DB table to use as a shield to skip publishing similar notifications or publish partial notifications (similar idea when processing notif)
+- Improve transactions to exclude similar messages by klass and action. Sample:
+    ```PubSubModelSync::MessagePublisher.transaction(key, { same_keys: :use_last_as_first|:use_last|:use_first_as_last|:keep*, same_data: :use_last_as_first*|:use_last|:use_first_as_last|:keep })```
+- Add DB table to use as a shield to prevent publishing similar notifications and publish partial notifications (similar idea when processing notif)
 - add callback: on_message_received(payload)
 
 ## **Q&A**
 - I'm getting error "could not obtain a connection from the pool within 5.000 seconds"... what does this mean?
   This problem occurs because pub/sub dependencies (kafka, google-pubsub, rabbitmq) use many threads to perform notifications where the qty of threads is greater than qty of DB pools ([Google pubsub info](https://github.com/googleapis/google-cloud-ruby/blob/master/google-cloud-pubsub/lib/google/cloud/pubsub/subscription.rb#L888))
-  To fix the problem, edit config/database.yml and increase the quantity of ```pool: 10```
-- Google pubsub: How to process notifications parallely and not sequentially (default 1 thread)?
-  ```ruby  PubSubModelSync::ServiceGoogle::LISTEN_SETTINGS = { threads: { callback: qty_threads } } ```
-  Note: by this way some notifications can be processed before others thus missing relationship errors can appear
+  To fix the problem, edit config/database.yml and increase the quantity of ```pool: 20```
 - How to retry failed syncs with sidekiq?
   ```ruby
     # lib/initializers/pub_sub_config.rb