Many tests are hard to read because the fixtures are placed in the spec files.

Bacseu fixtures take loads of space, it's better to store and group all file-based fixtures inside a sub-directory.

RSpec.describe SearchReport do
  let(:search_report) { create(:search_report) }
  let(:google_search_parser) { GoogleSearchParser.new('new york tours') }
  let(:html_source) {  File.read(Rails.root.join('spec', 'fixtures', 'google-result-page.html')) }

  describe 'Associations' do
    it { is_expected.to belong_to(:search_task) }
    it { is_expected.to have_many(:search_results).dependent(:destroy) }
  end

  [...]
end

Any specific reasons not to use resource_owner_authenticator in config/initializers/doorkeeper.rb?

Upon review of the implementation, the overall architecture seems sound but there are not unit or UI tests to back it up.

You are free to choose between MiniTest or RSpec but tests are required at the very least for:

• Models
• Jobs
• Services
• Systems (UI) specs for the main flow to upload and see search results

1. Not sure about the need to define process! in the model itself. Since it will only be used in the job, it could be defined there.

2. Use a transaction block to revert database changes in case of errors

3. Never rescue from Exception as it's the parent class of all errors, hence it could catch errors you don't want to catch

4. Use custom errors to map errors the app domain

5. Use Active Job hooks to perform actions after successful job completions

class ProcessSearchTaskJob < ApplicationJob
  def after_perform do |job|
    search_task.update_column(:state, :complete)
  end

  def perform(search_task)
    ActiveRecord::Base.transaction do
      search_task.update_column(:state, :processing)
      parse_keywords_and_create_reports
    end
  rescue StandardError => exception
    raise ActiveRecord::Rollback
    search_task.update_column(:state, :failed)
    raise Searchbot::Errors::ProcessKeywordError.new
  end
end

While Api::V1::SearchTasksController uses strong params: params.require(:search_task).permit(:name, :keywords_csv), the other APi controller does not.

In addition the params naming is a kind of cryptic:

params[:q]

Instead, it could be named fully as query.

In the params, this following is kind of hard to understand:

params[:q][:search_report_search_task_user_id_eq] = current_resource_owner.id

I am guessing this is required by ransack but it's a bit awkward and undocumented.
A better way would be to move this to a Service Class to remove this complexity from the controller. If this does not makes sense, minor improvements like this could help:

class SearchResultsController < BaseController
      def index
        search_result = SearchResult.ransack(search_params).result.includes(search_report: :search_task)
        [...]
        render json: search_tasks, load_associations: true, search_report_ids: search_report_ids, 
               earch_result_ids: search_result_ids, include: ['search_reports', 'search_results']
      end

      private

      def search_params
        params.require(:query)
        append_ransack_params
      end

      def append_ransack_params
        params.merge(search_report_search_task_user_id_eq: current_resource_owner.id)
      end
end

README should contain the basic details about the project, how to set it up and test.