Each background job retry gets its own Postgres row in a design built around tenant incident queries

The schema starts from one incident question. Given a tenant ID, an operation ID and a time range, an investigator should find the job and read its attempts in order. They should also be able to tell a retryable failure from terminal exhaustion and reach sanitized diagnostic detail ^[4]. I think designing from the query is correct. It limits storage to what an investigation reads, and the post calls that goal narrower than retaining every log forever ^[4].

The separate identifiers exist for one failure mode. If a single ID stands in for job, attempt and operation, an operator looking at two errors cannot tell a duplicate execution from two retries, according to the post ^[5]. Its summary of that case is two words: "Ambiguity wins." ^[19]

Existing tools each hold a fragment. The worker library scheduled the retry and the error tracker grouped the exception, but the post says neither is an incident history by itself ^[3]. A column called last_error is at least honest about how much it remembers ^[8]. Logs fail for other reasons: retention differs between systems, clocks disagree, and a line can be emitted before the transaction that claims the work has committed ^[9]. So the post makes append-oriented attempt rows the durable record and keeps the job's current status as a compact projection for the dispatcher ^[10].

Write order is what makes the row trustworthy. The Python sample mints a UUID, then inside a transaction inserts the attempt with job_id, operation_id, tenant_id, attempt_no, started_at and an outcome of 'running' ^[15]. Each attempt costs two writes, the insert and the close, and a later attempt never touches an earlier row ^[16]. The post calls the attempt immutable ^[13]. In practice it is updated once, when it closes.

The open row matters when a worker crashes. If the insert commits before the handler starts, a worker that dies mid-attempt leaves a committed row at 'running' ^[17]. That row exists whatever the logs managed to flush ^[9]. Something outside the worker still has to find it and close it ^[17].

What goes into the row is bounded. It holds timestamps, attempt number, outcome, an error class, a bounded message and a correlation key into detailed telemetry, and no session tokens, connection strings or raw request bodies ^[6]. The post cites OWASP's logging guidance for both halves of the sanitizer: do not record tokens or passwords, and sanitize event data against log injection ^[7]. The sample's clean_error runs a case-insensitive regex for authorization, password or token followed by an equals sign, and replaces the value with [REDACTED] ^[14]. It then turns carriage returns and newlines into spaces and cuts the message to 500 characters ^[14].

The line-break handling is sound. The redaction is narrower than it looks. The pattern needs a literal equals sign after the key, so an exception message carrying `Authorization: Bearer <token>`, or a JSON body with a quoted "token" field, passes through intact ^[18]. Parameter binding keeps the SQL statement safe ^[13]. The regex is what decides whether the evidence table ends up holding secrets, and as written it covers query-string syntax only ^[18].