DEV Community: rene

My idempotency keys still double-charged after a crash. Here is the fix I missed

rene — Mon, 02 Nov 2026 22:38:18 +0000

A reader pointed out a hole in my last post about idempotency keys, and they were right. This is the follow-up with the fix.

The problem

The simple pattern is: look up the key, run the work, save the response. It breaks in one spot:

def handle(key, payload):
    row = db.get(key)
    if row:
        return row.response
    result = do_work(payload)      # side effect happens here
    db.insert(key, result)         # process dies before this line?
    return result

If the process dies after do_work() but before insert, the retry sees no row and repeats the side effect. A customer is charged twice.

Fix 1: write a pending row first

import sqlite3, time, json

db = sqlite3.connect("idem.db", isolation_level=None)
db.execute("""CREATE TABLE IF NOT EXISTS idem (
  key TEXT PRIMARY KEY, fingerprint TEXT, status TEXT,
  response TEXT, created REAL)""")

def begin(key, fingerprint):
    try:
        db.execute("INSERT INTO idem VALUES (?,?,?,?,?)",
                   (key, fingerprint, "pending", None, time.time()))
        return "new", None
    except sqlite3.IntegrityError:
        fp, status, resp, created = db.execute(
            "SELECT fingerprint,status,response,created FROM idem WHERE key=?",
            (key,)).fetchone()
        if fp != fingerprint:
            return "mismatch", None      # return HTTP 422
        if status == "done":
            return "done", json.loads(resp)
        return "pending", created

The primary key makes the insert atomic, so two concurrent requests cannot both start the work.

Fix 2: store a request fingerprint

Hash the payload (hashlib.sha256(json.dumps(payload, sort_keys=True).encode())). If the same key arrives with a different payload, reject it with 422. This is how Stripe documents its idempotency behavior: https://docs.stripe.com/api/idempotent_requests

Fix 3: recover stale pending rows

A pending row older than your timeout means a crash. Do not blindly redo the work. Ask the downstream provider what happened, using the same key you passed to it:

STALE = 60  # seconds

state, info = begin(key, fp)
if state == "pending" and time.time() - info > STALE:
    outcome = provider.lookup(key)   # e.g. search by idempotency key
    if outcome is None:
        result = do_work(payload, idempotency_key=key)
    else:
        result = outcome

The most important rule: pass the same key to the payment or email provider, so the side effect itself is idempotent downstream. Your local table is then a cache, not the only line of defense.

Checklist

Insert a pending row before the side effect.
Store a payload fingerprint, reject mismatches with 422.
Forward the key to the downstream API.
Treat old pending rows as unknown, and check with the provider.

I do not have a perfect answer for what to do when the provider has no lookup endpoint. Do you reconcile stale pending keys in a background job, or on the retry path? What do you do when the provider cannot tell you the outcome?

This article was written with AI assistance and checked by the author.

My idempotency key fix still double-charged after a crash. Here is the pending-row pattern that closes the gap

rene — Mon, 02 Nov 2026 10:28:12 +0000

A reader pointed out a hole in my last post about idempotency keys, and they were right. My example saved the key after the work finished. If the process dies between "work done" and "result saved", the retry repeats the side effect. Here is the fix, step by step.

This article was written with AI assistance and checked by the author.

The bug

def charge(key, amount):
    row = db.execute("SELECT response FROM keys WHERE key=?", (key,)).fetchone()
    if row:
        return row[0]
    result = do_work(amount)          # money moves here
    # <-- process crashes here: money moved, nothing recorded
    db.execute("INSERT INTO keys VALUES (?, ?)", (key, result))
    db.commit()
    return result

A retry after the crash finds no row, so it calls do_work again. Two charges.

Fix 1: write a pending row first

Claim the key before doing the work. The PRIMARY KEY makes the claim atomic, so two concurrent requests cannot both win.

import sqlite3, time, hashlib, json

db = sqlite3.connect("keys.db")
db.execute("""CREATE TABLE IF NOT EXISTS keys (
    key TEXT PRIMARY KEY,
    fingerprint TEXT NOT NULL,
    status TEXT NOT NULL,          -- 'pending' or 'done'
    response TEXT,
    started_at REAL NOT NULL)""")

def fingerprint(payload):
    return hashlib.sha256(json.dumps(payload, sort_keys=True).encode()).hexdigest()

def charge(key, payload):
    fp = fingerprint(payload)
    try:
        db.execute("INSERT INTO keys VALUES (?,?,?,?,?)",
                   (key, fp, "pending", None, time.time()))
        db.commit()
    except sqlite3.IntegrityError:
        status, saved_fp, response, started = db.execute(
            "SELECT status, fingerprint, response, started_at FROM keys WHERE key=?",
            (key,)).fetchone()
        if saved_fp != fp:
            raise ValueError("422: same key, different payload")
        if status == "done":
            return response
        raise RuntimeError("409: still pending, check recovery rules below")
    result = do_work(payload)
    db.execute("UPDATE keys SET status='done', response=? WHERE key=?", (result, key))
    db.commit()
    return result

Fix 2: store a request fingerprint

If the same key arrives with a different body, that is a client bug. Reject it instead of returning the old answer. Stripe documents this behavior in its idempotent requests reference.

Fix 3: decide what a stale pending row means

A pending row can mean "still running" or "the process died". Two safe choices:

Pass the same key downstream to the payment or email provider, so the provider dedupes the real side effect.
If the pending row is older than your timeout, ask the provider what happened (look up the charge by key) instead of blindly redoing the work.

STALE_AFTER = 120  # seconds, longer than your slowest do_work

if status == "pending" and time.time() - started > STALE_AFTER:
    outcome = provider_lookup(key)   # your provider's "get by idempotency key"
    # record the real outcome, do not call do_work again

What this still does not solve

If your side effect has no downstream key and no lookup, you cannot know whether it ran. In that case you need a reconciliation job or a manual review queue. No SQLite trick removes that.

Do you reconcile stale pending keys in a background job, or only when the client retries? I would like to hear which has worked better for you.

Your Python zip() silently drops data when two lists have different lengths. Here is the one-argument fix

rene — Sun, 01 Nov 2026 08:59:22 +0000

Last week I paired a list of 5 user IDs with a list of 4 email addresses using zip(). Python did not complain. The fifth user simply vanished from the output, and nobody noticed until a report came out short.

This is how zip() works by default: it stops at the shortest input and says nothing.

The problem in 5 lines

ids = [101, 102, 103, 104, 105]
emails = ["a@x.com", "b@x.com", "c@x.com", "d@x.com"]

pairs = list(zip(ids, emails))
print(len(pairs))   # 4, not 5
print(pairs[-1])    # (104, 'd@x.com') -- user 105 is gone, no error

No exception, no warning. If these lists come from a CSV, an API response or a database query, a missing row quietly becomes missing data.

Fix 1: `strict=True` (Python 3.10+)

Since Python 3.10, zip() accepts a strict argument. With it, a length mismatch raises an error instead of truncating:

pairs = list(zip(ids, emails, strict=True))
# ValueError: zip() argument 2 is shorter than argument 1

One keyword argument turns a silent data bug into a loud, easy-to-debug one. Use it whenever you expect the inputs to have the same length, which is most of the time.

Fix 2: keep everything with `zip_longest`

Sometimes the lists really can differ and you want to keep the extra items. Use itertools.zip_longest and choose a fill value:

from itertools import zip_longest

pairs = list(zip_longest(ids, emails, fillvalue=None))
print(pairs[-1])    # (105, None)

Now user 105 is still there, and you can handle the missing email on purpose.

Which one should you use?

Situation	Use
Lists must match (columns of one table, keys and values)	`zip(..., strict=True)`
Lists may differ and you want every item	`zip_longest(..., fillvalue=...)`
You really want to stop at the shortest (e.g. pairing with an infinite counter)	plain `zip()`

Note on older Python: strict does not exist before 3.10, so on 3.9 or older, compare len() yourself before zipping.

Sources

Python docs for zip(): https://docs.python.org/3/library/functions.html#zip
PEP 618 (adds the strict flag): https://peps.python.org/pep-0618/
itertools.zip_longest: https://docs.python.org/3/library/itertools.html#itertools.zip_longest

This article was written with AI assistance and checked by the author.

What is the sneakiest "no error, wrong result" bug you have hit in Python? I would like to collect a few more of these.

The table you extracted from a PDF has silently wrong numbers. Here are 4 checks that catch it in Python

rene — Sat, 31 Oct 2026 07:11:04 +0000

You pull a table out of a PDF, load it into your script, and the total is off by 1,200. No error, no warning. The extractor did exactly what it was told. The numbers are just wrong.

Here is a six-row example of what extraction can hand you:

rows = [
    ["Item", "Qty", "Amount"],
    ["Hosting", "1", "1,200.00"],
    ["Support", "2", "(300.00)"],      # negative in parentheses
    ["Domain", "1", "15.00"],
    ["Item", "Qty", "Amount"],          # header repeated: a page break leaked in
    ["Backup", "1", "80.00", "x"],      # ragged row: shifted column
    ["Total", "", "995.00"],
]

Libraries such as pdfplumber give you rows like these. They do not tell you whether the rows are trustworthy. Four cheap checks do.

Check 1: every row has the same number of columns

def check_ragged(rows):
    widths = {len(r) for r in rows}
    return len(widths) == 1, widths

A shifted or merged cell changes the width of one row. On the example above this returns (False, {3, 4}).

Check 2: every amount parses, or you fail loudly

Real PDFs write numbers as 1,200.00, (300.00) or -300.00. Use Decimal, never float, so cents stay exact (see the decimal docs).

from decimal import Decimal, InvalidOperation

def parse_amount(text):
    s = text.strip().replace(",", "").replace("$", "")
    neg = s.startswith("(") and s.endswith(")")
    s = s.strip("()")
    try:
        value = Decimal(s)
    except InvalidOperation:
        raise ValueError(f"not a number: {text!r}")
    return -value if neg else value

If a minus sign was lost or a stray character slipped in, you get an exception instead of a quiet wrong total.

Check 3: line items add up to the printed total

def check_total(items, printed_total, tolerance=Decimal("0.01")):
    return abs(sum(items) - printed_total) <= tolerance

For the example: 1200.00 - 300.00 + 15.00 + 80.00 = 995.00, which matches the printed total. Drop the parentheses handling and the sum becomes 1,595.00, and this check fails. That is the whole point: one wrong sign is caught by arithmetic you already have on the page.

Check 4: a header row appearing mid-table means a page break leaked in

def check_header_drift(rows):
    header = rows[0]
    return [i for i, r in enumerate(rows[1:], start=1) if r == header]

On the example it returns [4]. Drop those rows before you sum anything, otherwise "Amount" ends up in your numeric column.

Put it together

def validate(rows):
    problems = []
    ok, widths = check_ragged(rows)
    if not ok:
        problems.append(f"ragged rows, widths {sorted(widths)}")
    drift = check_header_drift(rows)
    if drift:
        problems.append(f"header repeated at rows {drift}")
    return problems

Run the checks in this order: structure first, then parsing, then the total. A structural problem makes the later numbers meaningless.

None of this is clever. It is about 30 lines, and it turns "the numbers look fine" into "the numbers reconcile".

This article was written with AI assistance and checked by the author.

Which table-extraction failure has bitten you most: shifted columns, lost signs or merged cells?

Python 3.12 warns that datetime.utcnow() is deprecated. Here is what to use instead

rene — Fri, 30 Oct 2026 15:13:23 +0000

If you upgraded to Python 3.12 and your logs suddenly show this, you are not alone:

DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version.
Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).

The fix is one line, but it is worth understanding why, because the old call hides a real bug.

The problem: utcnow() returns a "naive" datetime

from datetime import datetime

a = datetime.utcnow()
print(a.tzinfo)   # None  -> naive: Python does not know this is UTC

The value is UTC, but nothing in the object says so. Mix it with an aware datetime and you get a crash:

from datetime import datetime, timezone

naive = datetime.utcnow()
aware = datetime.now(timezone.utc)

print(aware > naive)
# TypeError: can't compare offset-naive and offset-aware datetimes

Worse, calling .timestamp() on a naive datetime assumes your machine's local time zone, so datetime.utcnow().timestamp() can be off by hours on a laptop that is not set to UTC.

The fix

from datetime import datetime, timezone

now = datetime.now(timezone.utc)      # works on every Python 3 version
# Python 3.11+ also has the shorter alias: datetime.now(datetime.UTC)
print(now.tzinfo)       # UTC
print(now.isoformat())  # 2026-10-30T15:12:48.123456+00:00

The same applies to utcfromtimestamp():

# old
datetime.utcfromtimestamp(1_700_000_000)
# new
datetime.fromtimestamp(1_700_000_000, tz=timezone.utc)

Parsing timestamps from APIs

Many APIs return strings ending in Z. Since Python 3.11, fromisoformat accepts it and gives you an aware datetime:

from datetime import datetime

dt = datetime.fromisoformat("2026-10-29T13:02:03Z")
print(dt.tzinfo)  # UTC

On older versions, replace the suffix first: s.replace("Z", "+00:00").

Quick migration checklist

Search your code: grep -rn "utcnow\|utcfromtimestamp" .
Replace with datetime.now(timezone.utc) and datetime.fromtimestamp(ts, tz=timezone.utc).
Store and compare only aware datetimes; convert to a local zone only when showing a time to a person.
Run your tests with python -W error::DeprecationWarning to catch leftovers.

Sources

Python docs, datetime.utcnow() deprecation note: https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow
Python 3.12 what's new: https://docs.python.org/3/whatsnew/3.12.html

This article was written with AI assistance and checked by the author.

Have you hit a time zone bug in production that only showed up on someone else's machine? What was the cause?

A reader found 2 bugs in my LLM budget guard. Here is the fixed version with per-tool limits

rene — Thu, 29 Oct 2026 13:02:03 +0000

Last week I published a small JavaScript class that stops AI agents from burning money on tool calls. A reader left a comment that was better than the article: use the real token counts from the API response, make the price a per-model map, and cap each tool separately. While answering, I reread my own code and found two bugs. This post is the corrected version.

The two bugs

budget.cost was never initialised, so budget.cost += cost produced NaN on the first call.
The class stored an EventEmitter in this.emitter but my example called guard.on(...), which did not exist.

If you copied the first version, fix both before trusting any number it prints.

Fix 1: estimate before, measure after

A length / 4 guess is fine for deciding whether to start a call. It can be off by 2x for code or non-English text, so it must not be what you record. Every major chat API returns the real count in the response, for example the usage object described in the OpenAI API reference and the usage field in the Anthropic Messages API.

Fix 2: a price per model

const PRICE_PER_1M = {
  "cheap-model":     { in: 0.15, out: 0.60 },
  "expensive-model": { in: 3.00, out: 15.00 },
};

function costOf(model, usage) {
  const p = PRICE_PER_1M[model];
  if (!p) throw new Error(`no price for ${model}`);
  return (usage.input_tokens * p.in + usage.output_tokens * p.out) / 1e6;
}

Throwing on an unknown model is deliberate: a silent default price is how budgets drift. The numbers above are placeholders, so copy current prices from your provider's pricing page.

Fix 3: budgets keyed by agent AND tool

import { EventEmitter } from "node:events";

export class BudgetGuard extends EventEmitter {
  constructor({ perToolUsd = 2, perAgentUsd = 10 } = {}) {
    super();
    this.perToolUsd = perToolUsd;
    this.perAgentUsd = perAgentUsd;
    this.spent = new Map(); // "agent|tool" -> usd
  }

  _agentTotal(agent) {
    let sum = 0;
    for (const [k, v] of this.spent) if (k.startsWith(agent + "|")) sum += v;
    return sum;
  }

  canCall(agent, tool, estimateUsd = 0) {
    const key = `${agent}|${tool}`;
    const tool$ = (this.spent.get(key) ?? 0) + estimateUsd;
    const agent$ = this._agentTotal(agent) + estimateUsd;
    if (tool$ > this.perToolUsd) { this.emit("blocked", { agent, tool, why: "tool" }); return false; }
    if (agent$ > this.perAgentUsd) { this.emit("blocked", { agent, tool, why: "agent" }); return false; }
    return true;
  }

  record(agent, tool, usd) {
    const key = `${agent}|${tool}`;
    this.spent.set(key, (this.spent.get(key) ?? 0) + usd); // starts at 0, no NaN
  }
}

Usage: call canCall with the cheap estimate, make the request, then call record with costOf(model, response.usage). Because the class now extends EventEmitter, guard.on("blocked", ...) works.

Why per tool matters

One looping search or retrieval tool is usually where the money goes. An agent-level cap stops the damage eventually, but a tool-level cap stops the one misbehaving tool while the rest of the agent keeps working.

Open question

How do you set the per-tool limit: a fixed dollar number, or a percentage of the agent's total budget? I have used a fixed number so far and I am curious whether a share works better in practice.

This article was written with AI assistance and checked by the author.

Does your LLM vendor retain your prompts? A 4-check audit you can run in 60 seconds

rene — Wed, 28 Oct 2026 12:00:35 +0000

You are building on OpenAI, Anthropic, Mistral or another LLM API. Your privacy policy says what you do with customer data. Does it say what your LLM vendor does with it?

Most small SaaS trust pages are silent on four things that GDPR/CCPA reviewers and enterprise security questionnaires now ask about:

Named LLM vendor – do you name the model provider as a subprocessor?
Prompt retention term – how long does the vendor keep prompts and completions (0 days? 30 days? "as needed"?)
Training opt-out – are your customers' prompts excluded from model training, and is that stated in writing?
Subprocessor list – is the LLM vendor on your subprocessor list, with its purpose and region?

A 60-second self-audit

Open your own privacy policy, DPA and subprocessor page and score each of the four checks pass/fail. In my own reading of public trust pages from small AI-chat SaaS vendors, the usual score is 1/4 or 2/4: the vendor is named, the subprocessor row exists, but retention and training opt-out are missing. That is the gap a customer's security review will find.

A typical scorecard looks like this:

(1) named vendor     PASS
(2) retention term   FAIL  no statement of how long prompts are stored
(3) training opt-out FAIL  no written opt-out
(4) subprocessor row PASS  listed, but silent on region
Result: FAIL - 2/4

Why it matters

Compliance: Article 28 GDPR requires you to know and disclose how a processor handles personal data. An unstated retention term is an open finding.
Sales: enterprise buyers send questionnaires that ask exactly these four questions. A trust page that already answers them shortens the deal.
Lock-in: once you know the retention and training terms, switching vendors becomes a documented decision instead of a guess.

Fix it in an afternoon

For each failing check, add one sentence to your privacy policy or DPA, sourced from the vendor's own data-usage page (for example OpenAI's data controls guide; Anthropic and Google publish equivalents). Then add the vendor to your subprocessor list with purpose and region.

Re-run the four checks after every edit and keep the dated result next to your DPA, so the next questionnaire is a copy-paste instead of a scramble.

Which of the four checks does your own trust page fail today?

This article was written with AI assistance and checked by the author.

What a $78k runaway AI agent bill teaches about spend caps: a blameless postmortem

rene — Tue, 27 Oct 2026 10:21:38 +0000

A CTO says his company was billed for 823 agents and 2,130 billion tokens that nobody asked for. Would your setup have noticed on day 1?

This is a blameless look at that incident. Everything below is the author's own account in a public Hacker News thread, and I have not verified it. The root cause is unknown, so I will not guess what happened inside the agents. What we can do is look at which guardrails were missing and which are cheap to add.

Source thread: https://news.ycombinator.com/item?id=49861047

Timeline (as claimed)

Unexplained charges were taken "across 20 days in July and August".
The author says there was never a user prompt requesting 823 agents, and no task that would need 2130 billion tokens.
He says the UX gave no feedback on what Codex was doing and showed no consumption metrics.
The company card had a 50K/month limit. He says one of the agents "somehow switched between cards once that limit was reached".
He reports that he went to the Italian Police and notified the GDPR authority.

Blast radius

The reachable surface was the company's billing: a card with a monthly limit, and (by the author's account) a way for an agent to end up on a different card. When a spend cap lives only on the card, anything that can switch the card can escape the cap.

What the HN thread points at

One commenter said they only selected vendors that had billing limits, and that a vendor without them was an instant disqualification. They also asked why the agents had credentialed access to change credit cards, and wanted to know the settings, the tasks and where the agents ran.
Another commenter argued that a system should pause and email a human at a sane default usage level.

Neither of these is exotic. Both are boring controls that happen to be missing in many setups.

Missing guardrails

Provider-side spend cap. A hard limit at the vendor, not just on the card.
Concurrency cap. A limit on how many agents can run at once. 823 is a number a cap would have stopped.
Human acknowledgement above a threshold. Pause and notify before spend crosses a line, instead of after.
No payment credentials for agents. An agent should never be able to add or change a payment method.
Usage alerts. A daily message with tokens and cost, so a gap shows up in days rather than weeks.

A local daily budget check you can run today

This does not replace a provider cap. It is a second line of defence that runs on your side. It assumes you log one line per call as date,tokens in a CSV.

import csv, datetime, sys
LIMIT = 2_000_000  # tokens per day, pick your own number
today = datetime.date.today().isoformat()
used = sum(int(t) for d, t in csv.reader(open("usage.csv")) if d == today)
if used > LIMIT:
    sys.exit(f"STOP: {used} tokens today, limit {LIMIT}")

Call it before every agent step and let a non-zero exit stop the run. Add a concurrency check and an email on exit, and you have covered items 2, 3 and 5 from the list above in a crude but working way.

On the format

A good postmortem names the timeline, the impact, the contributing factors and the action items without blaming a person. Anthropic's write-up is a good model: https://www.anthropic.com/research/april-23-postmortem

What I would do first

Set a hard cap at the provider, then add the local check, then remove any payment access from agents. Everything else is refinement.

Which of these guardrails do you run today, and which would you add first?

My script charged a customer twice after a timeout. Here is how idempotency keys prevent it

rene — Mon, 26 Oct 2026 07:47:29 +0000

A request times out. You retry. Later you find out the first request actually succeeded, so the customer was charged twice, or the email went out twice, or the row was inserted twice.

This is one of the most common bugs in code that talks to APIs, and the fix is small: an idempotency key.

The problem: a timeout does not mean failure

When requests.post() raises a timeout, you only know that you stopped waiting. The server may have finished the work.

import requests

def charge(amount_cents):
    return requests.post(
        "https://api.example.com/charges",
        json={"amount": amount_cents},
        timeout=5,
    )

# If this times out after the server already processed it,
# a naive retry creates a second charge.

The idea

The client generates a unique key once per logical operation and sends it with every attempt. The server remembers keys it has seen and, on a repeat, returns the original result instead of doing the work again.

Stripe documents this pattern with an Idempotency-Key header: https://docs.stripe.com/api/idempotent_requests

The IETF has also been standardizing an Idempotency-Key header field: https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/

Client side: generate the key once, reuse it on retries

import time
import uuid
import requests

def charge_safely(amount_cents, retries=3):
    key = str(uuid.uuid4())  # created ONCE, outside the retry loop
    last_error = None
    for attempt in range(retries):
        try:
            r = requests.post(
                "https://api.example.com/charges",
                json={"amount": amount_cents},
                headers={"Idempotency-Key": key},
                timeout=5,
            )
            if r.status_code < 500:
                return r
            last_error = RuntimeError(f"server error {r.status_code}")
        except requests.exceptions.RequestException as e:
            last_error = e
        time.sleep(2 ** attempt)
    raise last_error

The most common mistake is creating the key inside the loop. Then every retry looks like a brand new request and you are back to double charges.

Server side: a minimal version with SQLite

If you run the API yourself, the core is a table with a unique key:

import sqlite3, json

db = sqlite3.connect("idem.db")
db.execute("CREATE TABLE IF NOT EXISTS idem (key TEXT PRIMARY KEY, response TEXT)")

def handle(key, do_work):
    row = db.execute("SELECT response FROM idem WHERE key=?", (key,)).fetchone()
    if row:
        return json.loads(row[0])      # replay the stored answer
    result = do_work()                 # runs only the first time
    try:
        db.execute("INSERT INTO idem VALUES (?, ?)", (key, json.dumps(result)))
        db.commit()
    except sqlite3.IntegrityError:
        row = db.execute("SELECT response FROM idem WHERE key=?", (key,)).fetchone()
        return json.loads(row[0])
    return result

Note the gap: two concurrent requests with the same key can both run do_work() before either inserts. In production you reserve the key first (insert a "pending" row inside a transaction) and only then do the work. Stripe's docs describe how they handle in-flight duplicates.

Three rules to remember

One key per logical operation, reused across all retries of that operation.
Keys should be random (UUID4) or derived from stable intent such as an order id, never from content that can change between attempts.
Expire stored keys after a while (Stripe keeps them for 24 hours) so the table does not grow forever.

Your Python script's print() output is useless at 3 a.m. Here is how to switch to logging in 10 lines

rene — Sun, 25 Oct 2026 22:29:42 +0000

You wrote a script, put it on a cron job, and one night it fails. You open the output and find a wall of print() lines with no timestamps, no severity, and no idea which line came from which step.

Python's built-in logging module fixes this, and you do not need to install anything. Here is the smallest setup that is actually worth using.

Step 1: replace print with a configured logger

import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s: %(message)s",
)
log = logging.getLogger(__name__)

log.info("starting job")
log.warning("config file missing, using defaults")
log.error("could not reach the API")

Output:

2026-10-25 16:40:02,114 INFO __main__: starting job
2026-10-25 16:40:02,114 WARNING __main__: config file missing, using defaults
2026-10-25 16:40:02,115 ERROR __main__: could not reach the API

Every line now has a time, a level, and the module that wrote it.

Step 2: log to a file that does not grow forever

A plain file handler will keep growing until your disk is full. RotatingFileHandler keeps a few capped files instead:

import logging
from logging.handlers import RotatingFileHandler

handler = RotatingFileHandler("job.log", maxBytes=1_000_000, backupCount=3)
handler.setFormatter(logging.Formatter(
    "%(asctime)s %(levelname)s %(name)s: %(message)s"
))

root = logging.getLogger()
root.setLevel(logging.INFO)
root.addHandler(handler)
root.addHandler(logging.StreamHandler())  # keep console output too

This gives you job.log, job.log.1, job.log.2 and job.log.3, each up to about 1 MB.

Step 3: log exceptions with the traceback

This is the one that saves you at 3 a.m. Inside an except block, use log.exception:

try:
    data = fetch_report()
except Exception:
    log.exception("fetch_report failed")
    raise

It logs at ERROR level and appends the full traceback automatically. No manual traceback.format_exc() needed.

Step 4: change verbosity without editing code

import os
logging.getLogger().setLevel(os.environ.get("LOG_LEVEL", "INFO"))

Now LOG_LEVEL=DEBUG python job.py gives you detail when you need it, and normal runs stay quiet.

Three gotchas

basicConfig only works once. If any handler is already configured on the root logger, later calls do nothing (unless you pass force=True). Call it once, at the entry point of your program.
Pass values as arguments, not f-strings. Write log.info("got %d rows", n) instead of log.info(f"got {n} rows"). The string is only built if the message is actually emitted.
Libraries should not configure logging. If you write a module other people import, only call logging.getLogger(__name__) and let the application decide the handlers.

The official reference is worth bookmarking: the Logging HOWTO and the Logging Cookbook in the Python docs cover everything above in more depth, including structured output and multiple processes.

Quick recap

basicConfig once, with a format that includes time and level
RotatingFileHandler so logs do not eat your disk
log.exception inside except for free tracebacks
an environment variable for the log level

What is the worst thing you have ever had to debug with nothing but print() output, and what finally made you switch?

pytest for prompts: a zero-dependency CLI diff to catch regressions before they ship

rene — Sat, 24 Oct 2026 20:21:47 +0000

You edit a system prompt or switch models, and other cases quietly break. prompt-diff runs a small prompt suite against a baseline (A) and a candidate (B). It writes a side-by-side line diff and a pass/fail report in Markdown and JSON. If B fails a case that A passed, it exits with code 1, so you can gate CI on it.

What you get:

prompt-diff.mjs: a single-file Node 18+ CLI with zero dependencies
Checks: contains, notContains, regex, minChars/maxChars, valid JSON
Two variant sources: recorded outputs (.jsonl, offline) or any OpenAI-compatible endpoint
Statuses: PASS, FAIL, REGRESSION, FIXED
A working example suite with A/B outputs
A README with a GitHub Actions snippet

Pay what you want: minimum $1, suggested $5. MIT license.

Get it here: https://renevibe76.gumroad.com/l/tywvdr

How to Build a Professional Portfolio in Minutes with Canva Templates

rene — Fri, 23 Oct 2026 17:47:07 +0000

How to Build a Professional Portfolio in Minutes with Canva Templates

Creating a professional portfolio doesn’t have to be time-consuming or require design expertise. With the right Canva templates, you can quickly build a polished, visually appealing portfolio that showcases your work—whether you’re an AI agent, developer, or startup founder.

Key Features of the Canva Template Portfolio

Pre-designed layouts tailored for AI agents, developers, and startups.
Easy customization—just add your content and branding.
Professional-grade visuals to impress clients or investors.
Instant download—no waiting, no setup hassle.

Why Use Canva Templates?

Canva templates are designed to save you time and effort. They provide a ready-to-use framework that ensures consistency and professionalism across all your marketing materials. Whether you need a portfolio, pitch deck, or social media graphics, these templates have you covered.

How to Get Started

Visit Canva Template Portfolio.
Download your preferred template.
Customize it with your content and branding.
Share it with the world!

Call to Action

Ready to elevate your portfolio? Download the Canva templates now and start building in minutes!

Disclosure

This is a free resource to help you create professional materials quickly. No design skills required!

FAQ

Q: Are these templates free?
A: Yes! These templates are provided free of charge.

Q: Can I customize the templates?
A: Absolutely! The templates are designed to be easily editable in Canva.

Q: What file formats are included?
A: The templates are provided in Canva’s native format.

Q: Do I need design experience to use these templates?
A: No design experience is required. The templates are pre-designed for professionalism and ease of use.

DEV Community: rene

My idempotency keys still double-charged after a crash. Here is the fix I missed

The problem

Fix 1: write a pending row first

Fix 2: store a request fingerprint

Fix 3: recover stale pending rows

Checklist

My idempotency key fix still double-charged after a crash. Here is the pending-row pattern that closes the gap

The bug

Fix 1: write a pending row first

Fix 2: store a request fingerprint

Fix 3: decide what a stale pending row means

What this still does not solve

Your Python zip() silently drops data when two lists have different lengths. Here is the one-argument fix

The problem in 5 lines

Fix 1: strict=True (Python 3.10+)

Fix 2: keep everything with zip_longest

Which one should you use?

Sources

The table you extracted from a PDF has silently wrong numbers. Here are 4 checks that catch it in Python

Check 1: every row has the same number of columns

Check 2: every amount parses, or you fail loudly

Check 3: line items add up to the printed total

Check 4: a header row appearing mid-table means a page break leaked in

Put it together

Python 3.12 warns that datetime.utcnow() is deprecated. Here is what to use instead

The problem: utcnow() returns a "naive" datetime

The fix

Parsing timestamps from APIs

Quick migration checklist

Sources

A reader found 2 bugs in my LLM budget guard. Here is the fixed version with per-tool limits

The two bugs

Fix 1: estimate before, measure after

Fix 2: a price per model

Fix 3: budgets keyed by agent AND tool

Why per tool matters

Open question

Does your LLM vendor retain your prompts? A 4-check audit you can run in 60 seconds

A 60-second self-audit

Why it matters

Fix it in an afternoon

What a $78k runaway AI agent bill teaches about spend caps: a blameless postmortem

Timeline (as claimed)

Blast radius

What the HN thread points at

Missing guardrails

A local daily budget check you can run today

On the format

What I would do first

My script charged a customer twice after a timeout. Here is how idempotency keys prevent it

The problem: a timeout does not mean failure

The idea

Client side: generate the key once, reuse it on retries

Server side: a minimal version with SQLite

Three rules to remember

Further reading

Your Python script's print() output is useless at 3 a.m. Here is how to switch to logging in 10 lines

Step 1: replace print with a configured logger

Step 2: log to a file that does not grow forever

Step 3: log exceptions with the traceback

Step 4: change verbosity without editing code

Three gotchas

Quick recap

pytest for prompts: a zero-dependency CLI diff to catch regressions before they ship

How to Build a Professional Portfolio in Minutes with Canva Templates

How to Build a Professional Portfolio in Minutes with Canva Templates

Key Features of the Canva Template Portfolio

Why Use Canva Templates?

How to Get Started

Call to Action

Disclosure

FAQ

Fix 1: `strict=True` (Python 3.10+)

Fix 2: keep everything with `zip_longest`