Proletarian does not depend on any logging framework. Instead of pulling in a logging library, it calls a function you provide whenever something notable happens during queue worker operation. This gives you complete control over how — and at what severity level — events are recorded.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/msolli/proletarian/llms.txt
Use this file to discover all available pages before exploring further.
Log function signature
The logging function is passed as the:proletarian/log option to worker/create-queue-worker. It must be a function that accepts two arguments:
event-keyword— a namespaced keyword that identifies the type of event (see the full list below).data-map— a map of contextual data describing the event, such as the job type, attempt number, and worker ID.
:proletarian/log option, the default is a println-logger that prints every event to standard output using println.
There is no “severity” or “level” built in to the log events. Proletarian does not decide whether an event is a debug message or an error — that determination is yours to make based on the event keyword and your application’s requirements.
Log event keywords
The following keywords are emitted by the queue worker during normal operation and error conditions:| Keyword | When it fires |
|---|---|
::worker/polling-for-jobs | A worker thread is about to poll the database for the next job |
::worker/handling-job | A job has been dequeued and is about to be executed |
::worker/job-finished | A job completed successfully |
::worker/job-interrupted | A job was interrupted mid-execution (e.g. during graceful shutdown) |
::worker/handle-job-exception | A job threw an Exception; retry logic will be evaluated |
::worker/handle-job-exception-with-interrupt | A job threw an exception but the thread interrupt flag was also set; job will be left in the queue |
::worker/job-worker-error | An unexpected Throwable was thrown during the poll/run cycle |
::worker/queue-worker-shutdown-error | An error occurred while stopping the queue worker |
::worker/worker-interrupted | A worker thread received an InterruptedException while polling |
::worker/sql-transient-exception | A transient SQL exception occurred during polling |
:proletarian.retry/retrying | A failed job is being scheduled for a retry |
:proletarian.retry/not-retrying | A failed job has exhausted all retries and will be archived as failed |
:proletarian.executor/shutting-down | The thread pool executor has begun shutting down |
:proletarian.executor/completed-shutdown | The thread pool executor finished shutting down cleanly |
:proletarian.executor/already-shut-down | stop! was called but the executor was already shut down |
:proletarian.executor/interrupted-while-shutting-down | The shutdown thread was itself interrupted while awaiting executor termination |
::worker/ prefix expands to :proletarian.worker/, so these keywords are fully qualified as e.g. :proletarian.worker/polling-for-jobs.
Data included in the data map
Thedata-map argument is merged from multiple context layers. Depending on the event, it may contain:
:proletarian.worker/queue-worker-id— the string ID of the queue worker (derived from the queue name unless overridden):worker-thread-id— the 1-based index of the worker thread within this queue worker:job-id— the UUID of the job being processed:job-type— the keyword job type:attempt— the current attempt number (1-based):exception/:throwable— the caught exception or error object, included on error events:retry-at— ajava.time.Instantindicating when a retried job will next be eligible for processing:retries-left— the number of remaining retries, included in retry events:retry-spec— the retry strategy map, included in not-retrying events
Example: integrating with clojure.tools.logging
The following example, taken directly from the Proletarian README, shows how to map event keywords to log levels and wire everything up using clojure.tools.logging:
log-level function acts as a dispatch table: exception-related events map to :error, polling maps to :debug, and everything else defaults to :info. Adjust the mappings to suit your monitoring and alerting requirements.