I idemkit after cleaning up duplicate charges one too many times.

The version everyone writes checks whether a key has been seen and replays the stored response. Two requests a millisecond apart both find nothing and both charge the card. And if the worker dies between charging and recording it, the retry charges again. Neither reproduces locally.

idemkit does it properly: an atomic claim instead of check-then-act, a lease that expires on the storage server’s clock, and a fencing token so a stalled worker can’t overwrite a good result.

from idemkit import idempotent, RedisBackend, MethodConfig 

@idempotent(
    backend=RedisBackend.from_url("redis://localhost:6379"), 
    config=MethodConfig(key_fields=["order_id"]), 
) 
async def charge(*, order_id, amount): 
    return await payments.charge(order_id, amount)

One core, three ways to use it: middleware for FastAPI/Flask/Django, a queue consumer wrapper or @idempotent on any function. Backends are Redis, Postgres, Mongo, DynamoDB, or in-memory for tests.

pip install idemkit, Apache-2.0: https://github.com/idemkit/idemkit

If you find it useful, I’d appreciate a star. It’s new, so visibility helps a lot right now.

  • thingsiplay@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    2 days ago

    Have you even understood what I told you? Edit: Where did they say they follow semantic versioning? You know, not every versioning has the same system. In example the Linux Kernel does not follow semantic, Firefox does not follow semantic and so on.

    • TehPers@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 days ago

      I don’t know why it’s worth arguing (both of you) over the versioning scheme of a LLM-assisted/generated project that was posted by a new user with no other activity, but anyway…

      PyPi (and Python) do not require semver, nor do all packages in the ecosystem use semver. However, Python tooling depends on packagers following a semver-esque versioning scheme while still allowing some freedom to maintainers to pick a scheme that works best for them.

      • hades@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        2 days ago

        Oh yeah, for sure. I just teel that I personally would never dare to release the first version of a library as 1.0.

      • thingsiplay@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        2 days ago

        I’m not arguing over versioning scheme, just explained to the guy above me that the initial version number of 1.0 does not matter. He was the one who started talking about semver. I literally said that it does not matter to argue about the versioning… my goodness. Is my English really that bad?

        Edit: Just for anyone who still didn’t understood: It does not matter if the first version is 0.x based or 1.x based, you can do ANY kind of versioning following that, even semver. The initial version number does absolutely not matter.