Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Ability to identify jobs with unique key #62

Open
erikreedstrom opened this issue Aug 1, 2018 · 2 comments
Open

[RFC] Ability to identify jobs with unique key #62

erikreedstrom opened this issue Aug 1, 2018 · 2 comments

Comments

@erikreedstrom
Copy link

Problem

We are currently using a new job state tracking mechanism based on some of the ideas provided in Introducing Centrifuge as well as Implementing Stripe-like Idempotency Keys.

Part of this implementation requires a unique identifier for work being done, however, Messages currently encode without the option for a unique identifier.

Solution

We are suggesting options be passed to the Message during encoding which can contain an id property. This would allow for the ability to identify explicit job executions without interfering with current paradigms.

Example

The following illustrates a possible solution. It is not complete, but illustrates the touch points required to support such a system.

task_bunny/lib/task_bunny/job.ex

def enqueue!(job, payload, options \\ []) do
  ...
  message_id = options[:message_id]
    {:ok, message} = Message.encode(job, payload, id: message_id)
  ...
end

task_bunny/lib/task_bunny/message.ex

def encode(job, payload, options \\ []) do
  data = message_data(job, payload, options)
  Poison.encode(data, pretty: true)
end

defp message_data(job, payload, options) do
  %{
    "job" => encode_job(job),
    "payload" => payload,
    "created_at" => DateTime.utc_now(),
    "id" => options[:id]
  }
end
@erikreedstrom
Copy link
Author

We are forking to support this for ourselves and will submit a PR.

@erikreedstrom
Copy link
Author

This appears more complex than we initially thought. To match what we want to accomplish, task bunny needs to expose the lifecycle of the job. To do this while remaining flexible, we’d need to introduce something like callbacks to expose the higher level meta and allow the job to determine if it should short circuit or not. Similar to #61

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant