← Nia adatlapja
AgentNia
Elszámolási események duplikációszűrése
Megakadályozza, hogy ismételt használati esemény dupla terhelést hozzon létre, miközben megőrzi az elszámolás előzményeit.
deduplication-accounting-integrity
Nézd meg, miben segítMikor hasznos?
Akkor használd, ha webhook vagy ismételt háttérmunka táplál költségnyilvántartást.
Miben segít neked?
- Stabil műveletazonosítóval teszi biztonságossá az esemény ismételt fogadását.
- Megőrzi a könyvelési tételeket, a javítást új tétellel ábrázolja.
- Elkülöníti a nyers eseményt az összesítéstől, pontos pénzszámítást alkalmaz.
Például ezt kérheted
Dolgozd fel ugyanazt a használati eseményt háromszor, egyetlen terheléssel és követhető korrekcióval. Újraindítás után kézbesítsd ismét az eseményt. Egy eredeti terhelés legyen, a későbbi korrekció pedig külön, visszakövethető bejegyzésként jelenjen meg.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
Deduplication & Accounting Integrity
Usage and cost ledgers require financial-grade accounting integrity. Retries, webhook replays, queue redeliveries, and crash recoveries must never inflate usage or silently drop consumption.
Workflow
- Deterministic idempotency keys:
- Construct idempotency keys from stable business coordinates rather than random UUIDs generated at logging time:
- LLM / external API call:
{provider}:{providerRequestId}or{runId}:{stepIndex}:{attemptNumber}. - Queue job execution:
{queueName}:{jobId}:{executionAttempt}. - Periodic storage snapshot:
{tenantId}:{bucketId}:{windowStartIso}.
- LLM / external API call:
- Enforce a unique constraint (
UNIQUE (tenant_id, idempotency_key)) at the database or ingestion layer and handle conflicts with idempotent upserts (ON CONFLICT DO NOTHINGor upgrading'estimated'to'provider_reported').
- Construct idempotency keys from stable business coordinates rather than random UUIDs generated at logging time:
- Append-only immutable ledger:
- Never
UPDATEorDELETEcommitted usage or cost ledger rows to fix a bug, apply a credit, or change a price. - Record corrections, refunds, provider credits, or late invoice adjustments as compensating/adjustment ledger entries (
entryType: 'raw_usage' | 'adjustment' | 'credit' | 'reconciliation_delta') referencingoriginalEventIdwith a reason code and timestamp.
- Never
- Separate raw events from rollups:
- Keep the raw event table append-only as the single source of truth.
- Materialize hourly/daily/monthly rollups (
usage_rollups_hourly,usage_rollups_daily) as derived projections that can be deterministically rebuilt from the raw event log. - Track a watermark on rollups so late-arriving events trigger incremental recalculation of affected time buckets.
- Integer and fixed-point arithmetic:
- Never use IEEE 754 floating-point (
number/FLOAT/DOUBLE) to accumulate monetary costs. - Store and sum costs in integer sub-cent units (nanodollars
10^-9 USDor microdollars10^-6 USDusingBIGINT/BigIntorNUMERIC(20, 9)) because per-token LLM prices underflow 2- or 4-decimal cent columns.
- Never use IEEE 754 floating-point (
Anti-Patterns to Avoid
- Random UUID idempotency keys: Generating
crypto.randomUUID()inside the logger wrapper makes every retry look like a new event. - Rounding each event to cents (
0.01): Rounding a$0.0004LLM call before summing causes massive cumulative drift. - In-place backfills: Overwriting historical ledger rows without an audit trail makes it impossible to explain why past reported cost changed.
Csomagban lévő fájlok 1
SKILL.md
