Skip to content

mammoth-io 0.8.52

Choose a tag to compare

@ankitkpandey1 ankitkpandey1 released this 26 Oct 09:29
· 103 commits to main since this release
db40e1b

Added (mammoth-io 0.8.52)

  • SDK: conditional reads. A GET whose response had an ETag is sent again with If-None-Match, and a 304 Not Modified returns the kept body, so an unchanged resource is not downloaded twice. This covers every route the API tags (workspaces, users, projects, folders, browse, datasets, views, project resources) without a per-route list. The server changes a tag on every change event (a pipeline's status and row count included), and any write the client sends empties the kept bodies first. MammothClient.etag_cache is the store. By default it's MemoryETagCache, bounded by entry count and bytes; MemoryETagCache.scoped(name) gives one caller their own share of a cache that many callers use. Pass any mammoth.etag.ETagCache to keep the bodies elsewhere, or None to turn this off. With a token_provider, the kept bodies are keyed by the token sent too, so a client serving many users never offers one user's body to another.
  • SDK: writes are safe to retry. Every write except a file upload carries a fresh Idempotency-Key (a caller's own key is kept). Once a response from the server echoes the key, the server is known to run a keyed write only once. From then on, a write whose connection dropped after it was sent, that got a 502/503/504, or that is still running from the first attempt (409 4GENR038) is sent again with the same key, at most twice, and runs once. A server that has never echoed a key gets no replays, as before. mammoth.client.honours_idempotency_keys(base_url) and mark_idempotency_keys_honoured(base_url) read and set what a process knows. If the write is still running after the retries (409 4GENR038), the error says operation_state outcome_unknown, not failed: it may still finish, so it must not be sent again.