How a Retry Bug Double-Charged a Customer $340 and Exposed a Systemic Flaw

·1 views

A software team discovered a critical payment bug after a customer reported being billed $340 twice within four seconds for the same order. The root cause was a checkout service that automatically retried timed-out payment requests, not realizing the original charge had already succeeded on the processor's side. Further investigation revealed that multiple other endpoints — including refund issuance, subscription upgrades, and bulk invites — shared the same vulnerability. The team resolved the issue by implementing idempotency keys, which use a client-generated UUID to detect and block duplicate operations before they execute. Since deploying the fix across all four affected endpoints, duplicate-charge and duplicate-refund support tickets have been effectively eliminated.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Codename One Adds On-Device AI and MCP Debugging Tool Across Mobile and Desktop

Open-source cross-platform framework Codename One has merged on-device AI capabilities and Model Context Protocol (MCP) support via a loopback socket in its latest release. The AI surface is organized into three packages covering vision tasks like OCR and face detection, language operations such as translation and identification, and reusable inference sessions for custom TensorFlow Lite models. Android leverages ML Kit while Apple platforms use Vision, Core Image, and Natural Language frameworks, with CPU fallback available where hardware acceleration is absent. All processing runs locally on the device, meaning no images, text, or tensors are sent to Codename One's servers, offering a narrower data exposure path for sensitive content. The MCP channel, designed primarily as a debugging tool, listens only on a loopback socket, limiting its exposure as a potential external control interface.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Solo developer shares hard-won lessons building a production-grade AI agent

A self-taught developer with a civil engineering background built a personal AI assistant over time, expanding it into a complex system with memory layers, routing logic, caching, and quality monitoring. Through hands-on experimentation, they discovered that most failures stemmed not from the AI model itself but from the surrounding infrastructure handling sessions, context, and tool calls. They found that prompt cache hit rates depend heavily on request structure stability rather than model capability, achieving around 66–80% cache hits only after standardising prefixes. Routing requests to cheaper models also proved unreliable in multi-turn conversations, where full context and memory are needed to interpret follow-up messages correctly. The developer concludes that real-world agent performance is shaped by workload design and system architecture, not by benchmark results.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Redis-py Bug Caused False Max Capacity Errors in Async Cluster Connections

A bug in redis-py, the Python client for Redis, caused spurious MaxConnectionsError exceptions in asynchronous cluster setups despite connection capacity being available. The issue arose when a closed connection marked for reconnect was deferred to a background task, leaving a brief window where the pool appeared full to concurrent requests. During this single event-loop gap, any new acquire attempt would incorrectly find the free queue empty and the connection count at its limit. The fix, proposed in PR #4256 addressing issue #4247, ensures that already-closed connections skip the background disconnect task and immediately return their slot to the free pool. A deterministic regression test using asyncio.Event objects was also added to reproduce the exact race condition and verify the corrected behavior.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

How Go Evolved from Cooperative to Signal-Based Goroutine Scheduling

Go's concurrency model relied on cooperative preemption at function prologues until version 1.10, allowing goroutine switches only at compiler-inserted safe points to support precise garbage collection. This approach caused serious issues, including cases where a goroutine spinning on an atomic load could starve other goroutines and halt the program entirely. Attempts to fix this by adding preemption checks at loop back-edges proved costly, with the most efficient method still slowing benchmarks by a geomean of 7.8% while introducing debugger conflicts. Starting with Go 1.14, the language switched to signal-based non-cooperative preemption, using the POSIX signal SIGURG to interrupt running goroutines and capture their CPU state without requiring their cooperation. SIGURG was chosen because it is debugger-friendly, not used by libc in mixed Go/C binaries, and largely irrelevant in modern applications due to the near-obsolescence of out-of-band socket data.

0 comments Read more at DEV Community