Mike Buhot

I'm guessing this is caused by EctoJob accessing the Repo before your test_helper.exs file gets a chance to put the DB in sandbox mode?

Awesome @joshuataylor ! You can probably prototype the UI by adding some triggers to your DB to do the `pg_notify` after update / delete on the queue table. I’m wondering...

How about embedding the UI within the Phoenix Live Dashboard? It looks like support for custom pages is going to be available soon: https://github.com/phoenixframework/phoenix_live_dashboard/issues/139 Metrics could be exposed via telemetry...

@blisscs this is the first report I’ve had if ecto_job “just stop working”. Do you have any log output?

Thanks for this PR @ramondelemos 👍 One question I have regarding idempotent jobs: would it be more useful if the jobs were retained in the database in a "completed" state...

Wow thanks @ramondelemos! I'll make some time to review this in detail this week.

Yes the `Postgrex.Notifications` listener consumes a DB connection that isn't from the Repo pool. Where would you expect to see such information? Perhaps in the https://github.com/mbuhot/ecto_job#how-it-works section of the readme?

Looks pretty good to me 👍 For the package name, I’d prefer we either 1) use `mbuhot.eskotlin.aggregation` to match the existing aggregation builders Or 2) move the filter / nested...

Work has started in #30

We've recently implemented a simple middleware to export counts and timings from Exq to StatsD via ExStatsD in the same format as [sidekiq pro metrics](https://github.com/mperham/sidekiq/wiki/Pro-Metrics) Would you be interested in...