Workhorse Benchmark v1

Prompt

You are the IMPLEMENTATION ENGINEER, not the reviewer. Build a production-ready supplier invoice payment service for a multi-tenant farm management SaaS. Stack: - TypeScript strict mode, Node.js 24 - PostgreSQL 16 - pg library - No ORM - Money stored as integer VND (BIGINT in PostgreSQL) Existing tables: invoices( id TEXT PRIMARY KEY, tenant_id TEXT NOT NULL, amount_vnd BIGINT NOT NULL, paid_vnd BIGINT NOT NULL DEFAULT 0 ) actor_grants( tenant_id TEXT NOT NULL, actor_id TEXT NOT NULL, permission TEXT NOT NULL ) Implement: recordSupplierPayment(ctx, input, pool) ctx = { tenantId: string, // authenticated server context actorId: string } input = { invoiceId: string, amountVnd: number, idempotencyKey: string } Business requirements: R1. Tenant comes only from ctx. Never trust a client-provided tenant. R2. Actor must have the pay_supplier_invoice permission in the authenticated tenant. R3. Invoice must belong to that tenant. A cross-tenant invoice must not be exposed. R4. Amount must be a positive safe integer. Reject fractions, NaN, Infinity and unsafe integers. R5. Total payments must never exceed invoice amount, including simultaneous requests. R6. Same tenant + idempotency key + identical payload must return the original payment, with no additional deduction. R7. Same tenant + idempotency key + different payload must return a conflict. R8. Payment creation and invoice paid_vnd update must be atomic. R9. A failed operation must leave the database unchanged. R10. A retry after a network timeout must not create a duplicate payment, even if the first transaction committed. R11. Do not rely on undocumented RLS, triggers, middleware or application-level mutexes. R12. Sensitive errors must not reveal another tenant's financial records. Your deliverables: 1. SQL migration for a payments table with appropriate constraints and indexes. 2. Complete TypeScript implementation using parameterized SQL and database transactions. 3. Concurrency-safe logic for both: - Two requests with different idempotency keys that would overpay the same invoice. - Two concurrent requests with the same idempotency key. 4. At least 8 executable integration tests using PostgreSQL, including a true concurrency test. 5. Correct error classes and HTTP status mapping. 6. A short explanation of transaction boundaries, row locking, idempotency behavior and rollback. Important: - Do not merely describe the solution. - Produce implementation and tests. - Do not omit difficult sections. - Do not use an in-memory lock. - Do not claim tests passed unless you actually executed them. - If execution tools are unavailable, explicitly say NOT EXECUTED. - Keep the implementation minimal. Avoid unrelated features and unnecessary abstractions.