标签：#bug

I never set out to build VentureTwin AI as just another chatbot. The idea was much bigger than answering questions. I wanted to build a digital twin that could understand a student's entire journey—their projects, certifications, technical skills, academics, achievements, and career interests—and use all of that to provide meaningful career guidance. Instead of simply recommending jobs based on keywords or certificate counts, I wanted the system to answer a much harder question: What is this student actually good at, and where are they most likely to succeed? To make that possible, I designed the platform as a collection of independent intelligence modules. The Certificate Intelligence module retrieved and verified certifications. Resume Intelligence evaluated technical skills and experience. Project Intelligence analyzed project metadata such as technology stack, complexity, implementation, and impact. Each module produced its own output, which was then passed to a scoring engine that generated a Career Readiness Score. Individually, every module worked exactly as expected. Then I compared two student profiles. The first student had completed more than 20 online certifications but had only a couple of basic projects. The second student had fewer certifications, but had built full-stack applications, worked with AI models, contributed to open-source projects, and actively participated in hackathons and technical competitions. I expected the second profile to receive stronger recommendations. It didn't. Instead, the student with the larger collection of certificates consistently received the higher Career Readiness Score. At first, I assumed something was broken. I traced every stage of the scoring pipeline, inspected API responses from every module, verified the PostgreSQL records, and even recalculated the scores manually. Every value matched. Every API response was correct. The database contained exactly what it should. The scoring engine was behaving exactly as I

I was testing NodeDB-Lite and PageDB through a real memory-layer application built on top of them. NodeDB-Lite is the embedded form of NodeDB for local-first and in-process workloads, while PageDB is the encrypted page store underneath it. That application was part of the test strategy. I did not want to validate the storage stack only through unit tests, fixtures, and controlled benchmarks. I wanted a real workload to keep using it, stress it, restart it, grow its data, and exercise the boundaries that isolated tests usually miss. Then the store became corrupted. The visible symptom was an authenticated-page read failure around an FTS path. A page that should have passed its AEAD authentication check did not. The application restarted, opened the same damaged store, hit the failure again, and fell into a restart loop. The hard part was not proving that the store was corrupt. The hard part was reproducing how it became corrupt. I could not reproduce it inside PageDB . I could not reproduce it through NodeDB-Lite . I could not even make the application produce it on demand. I could use the application normally for a while and eventually see the failure, but I did not have a deterministic sequence that caused it. By the way, I still found bugs along the way. Some were real. Some looked close enough to the corruption path that I thought I had finally found the root cause. I fixed them, rebuilt, ran the tests, and went back to dogfooding. The corruption still came back. At that point, I stopped asking: Which storage bug looks plausible? The real question was: Where does it actually go wrong? I kept testing the wrong shape of failure My strongest theory was freed-page reuse, or something close to a use-after-free inside the store. It was a reasonable theory. If a page had been released and then reused while another structure still referenced it, a later authenticated read could land on bytes that were valid somewhere else but invalid for the page the reader expected. So

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . Project Overview Staxa is a multi-tenant deployment platform I am building solo under Stackforge Labs. The backend is a single Go binary ( staxad ) using the chi router, with about 60 API endpoints, running on K3s on a Hetzner CAX21 ARM64 server that costs around $11/month. Each tenant gets an isolated Kubernetes namespace with their own app container, a PostgreSQL 16 or MySQL 8 database, a subdomain with automatic SSL, and resource quotas. Container builds run through Buildah, and the frontend is Next.js (App Router) with shadcn/ui and Clerk for auth. Bug Fix or Performance Improvement The symptom: POST /api/v1/tenants/{id}/deployments/{depId}/rollback accepted a deployment ID in the URL path and then completely ignored it. Whatever version you asked for, you got the most recent successful deployment instead. The route was wired up correctly in internal/api/router.go:149 : r . Post ( "/tenants/{id}/deployments/{depId}/rollback" , srv . handleRollbackDeployment ) But handleRollbackDeployment never called chi.URLParam(r, "depId") . It read {id} for the tenant and stopped there. How I found it: I was auditing my published API docs against the actual handlers, endpoint by endpoint. When I got to the rollback entry I went to write down what {depId} did, went to the handler to confirm, and found nothing reading it. The docs described an ID that the code never looked at. The worst part is that it returned 202 Accepted and then performed a real, successful rollback. Just not the one you asked for. There was no error to notice, no failed request in any log. The frontend had been passing the deployment ID into the URL since it was written ( src/lib/api.ts ), so the UI always believed the parameter was honored. Root cause: the handler created a rollback deployment row with no reference to any target, and the worker independently decided what to restore. In internal/worker/pipeline.go , runRo

I run a small script called reply_comments.py that scans my DEV.to articles for comments I haven't replied to yet, and hands me a JSON list so I can draft responses. It's been running twice a day for over a week. This morning, while re-reading it for something unrelated, I noticed the function that decides whether a thread still needs my attention was answering the wrong question — and had been since the day it was written. Here's the function, unchanged until today: def replied_by_me ( comment ): return any ( c [ " user " ][ " username " ] == ME or replied_by_me ( c ) for c in comment [ " children " ]) It walks a comment's entire reply tree and returns True the moment it finds any message from me, anywhere in the subtree. Then pending() uses it as the skip condition: for c in api ( f " /comments?a_id= { a [ ' id ' ] } " ): if c [ " user " ][ " username " ] == ME or replied_by_me ( c ): continue ... out . append ({...}) The logic reads fine in isolation: "did I already reply to this thread? Skip it." The bug is in what "already replied" is being asked to mean. replied_by_me doesn't check whether the latest message in the thread is mine — it checks whether a message from me exists at all, ever, at any depth. Those are the same question exactly once: the first time someone comments and I reply. They stop being the same question the moment the other person replies again. Proving it I wrote a small repro against the real function rather than trusting my read of it: from reply_comments import replied_by_me thread = { " id_code " : " 3c00h " , " user " : { " username " : " alexshev " }, " created_at " : " 2026-07-24T08:00:00Z " , " children " : [ { " user " : { " username " : " enjoy_kumawat " }, " created_at " : " 2026-07-25T10:00:00Z " , " children " : []}, { " user " : { " username " : " alexshev " }, " created_at " : " 2026-07-26T09:00:00Z " , " children " : []}, ], } print ( replied_by_me ( thread )) # True That's True even though the second child — posted a full day

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. The...

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . Written with the help of AI (Claude). The bug, the fix, the validation setup, and every claim below are mine, and were verified against the real codebase and a real full disk. The report Someone lost a Magic: The Gathering decklist. They were playing on Cockatrice — the open-source MTG client — with their decks on a drive that had quietly filled up while Oracle pushed an update in the background. They added a card, hit Ctrl+S, and Cockatrice said it saved. The debug log agreed: [2026-05-28 22:31:42.031 I] Saved deck to "G:/cockatrice300/data/decks/edh-b2-gitrog-reanimate.cod" with format 1 - true - true . Success. The file was 0 bytes. The deck was gone. That was issue #6952 , filed by Mekkiss. The steps to reproduce are four lines long and completely damning: Have a full disk. Open a deck on the full disk Add one card to it Save the deck (ctrl+s) Observe that the deck is now a 0 byte file. Three ways to be wrong at once The save path lived in DeckLoader::saveToFile() . Stripped down, it looked like this: QFile file ( fileName ); if ( ! file . open ( QIODevice :: WriteOnly | QIODevice :: Text )) { qCWarning ( DeckLoaderLog ) << "Could not create or open file:" << fileName ; return std :: nullopt ; } bool success = false ; switch ( fmt ) { /* ... saveToFile_Native / saveToFile_Plain ... */ } file . flush (); file . close (); qCInfo ( DeckLoaderLog ) << "Saved deck to " << fileName << "with format" << fmt << "-" << success ; There are three independent failures stacked on top of each other here, and you need all three to lose data: 1. WriteOnly truncates on open. The instant open() succeeds, the existing deck is 0 bytes. Not after a successful write — at open time . The old deck is already destroyed before a single byte of the new one is written. On a full disk, open() still succeeds: truncating a file doesn't need free space. It frees space. 2. The serializers always returned true . sa

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . "The best debugger is a well-rested mind armed with the right tools and a stubborn refusal to give up." The Call to Adventure It started like any other day. I was browsing GitHub, coffee in hand, when I stumbled across a repository that made me pause. The issue tracker was filled with bug reports that all had something in common. They were being ignored. Not because the maintainers did not care, but because these bugs were hard. They were the kind of bugs that hide in race conditions, platform edge cases, and security blind spots. The kind that make you stare at the screen for hours before the answer finally clicks. I am Aniruddha Adak , an AI Agent Engineer and Full-Stack Developer who builds autonomous systems. You can find my work on GitHub , read my blog at aniruddha-adak.vercel.app , or follow me on X and DEV . Over the past several months, I went on a bug-smashing spree that resulted in 373 merged pull requests across the open source ecosystem. This is the story of the most chaotic, educational, and rewarding debugging journeys from that adventure. Story One: The Security Breach Nobody Saw Coming The Project cognee is an open source AI memory infrastructure project. Think of it as the long-term memory system for AI agents. It stores, retrieves, and connects knowledge across conversations. It is ambitious, complex, and used by developers who need their AI systems to remember things. The Discovery I was reviewing the API layer, tracing how settings were updated. The POST /api/v1/settings endpoint caught my attention. It accepted a JSON payload and updated global configuration directly. No privilege check. No role verification. Just raw, unauthenticated power handed to anyone with a login token. My stomach dropped. In a production deployment, this meant any user could change LLM API keys, modify database connections, alter authentication settings, or disable security features entir

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. I...

We spoke with several cybersecurity researchers, who look for unknown vulnerabilities and develop tools to exploit them, about how OpenAI’s and Anthropic’s guardrails affect their work.

How gen_ai.invoke_agent spans revealed one tool was dumping 7x more output than its siblings. The fix: pagination + a token budget guard. 42% output reduction, 21% faster agent.

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . 🦄 I debated writing this for a long time, but I finally talked myself into really writing again after a hiatus, and there's no better way than story time. So here's one of the most challenging bugs—or really, the series of them—I've run into in the enterprise world. Grab some popcorn and Skittles, because this one takes a while. Better yet, cue up Jerry's actual theme song— Jerry Was a Race Car Driver by Primus , because of course it is —and let the best bass player on the planet score the whole mess while you read. And yes, it's the Summer Bug Smash and my entire cast is dressed for Christmas. Stay with me. Meet Jerry 🪦 If you work with software any length of time, you already know the particular nightmares that come with legacy applications. This one is no different. It started life as a rewrite of some antiquated, bash-flavored system back when Java 8 was the coolest kid at the table. Let's call him Jerry. Jerry is a well-rounded app—or he was, before he let himself go. He came up on a then-modern Java stack and served exactly one purpose: get data from upstream into the database, correctly and on time. He was good at his one job. Then his one job got split into parts, and the sum of those parts did not add up to a whole—Jerry just expanded along the midline with no particular purpose or direction in life. You can imagine how it goes: a few retirements, a couple of half-finished rewrites, several well-meaning somebodies who swore they'd whip him into shape and left him half-done every time. Take your eyes off him at Christmas and he's the weird uncle who shouldn't have been left alone with the punch. That's about when Jerry and I met, more than three years ago. The Infestation Begins 🪰 Jerry did his best to keep up with everything we kept piling on him, but communication was never his strong suit—a patch here, an upgrade there, enough to keep the lights on and the punch bowl full.

GitHub is making some significant changes to its bug bounty program, shifting its focus to give researchers a better experience working with the GitHub team. The post Next chapter: Restructuring GitHub’s bug bounty program appeared first on The GitHub Blog .

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry . Project Overview I recently deployed the Dograh AI voice agent (named Zoya) live on my production website, Mobile One Media , to handle client inquiries for our 4K video production, audio engineering, and app development services. For the first 48 hours, the agent worked flawlessly. However, on day three, it suddenly stopped responding on the live site. Users were experiencing complete hang-ups when trying to navigate the service menu. This wasn't a local testing issue; this was a live production fire that needed immediate debugging and a permanent fix. Bug Fix or Performance Improvement The Problem: Issue: After ~48 hours of continuous uptime, the live Dograh AI widget on mobileonemedia.com began silently failing, resulting in infinite loading states and dropped user sessions. Impact: 100% of new agent interactions were failing, directly blocking potential client leads from contacting our media production services. Root Cause: A Docker container configuration issue combined with a system prompt misalignment. The agent's Docker environment variables were not properly persisting the workflow state, and the system prompt was failing to initialize correctly after container restarts, causing the agent to lose conversational context. Code and Video Demo GitHub Pull Request: https://github.com/dograh-hq/dograh/pull/287 Watch the live agent in action: https://youtu.be/pKUxtq8sKDs?si=r1s2LK7zGIzpd2Ry The Fix Summary: Archived the old, messy agent configuration that was causing the Docker and prompt issues. Built a brand new, clean agent setup from scratch with proper architecture. Rebuilt the Docker container configuration with proper environment variable persistence and volume mounting. Fixed the system prompt initialization sequence to ensure it loads correctly on container startup. Added health check endpoints to monitor agent readiness before accepting user connections. My Improvements

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. I originally...

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . This is our official submission for the DEV Big Summer Bug Smash challenge under the #bugsmash track. Below is the technical tale of how we isolated, debugged, and optimized cross-layer node latency issues when deploying our Web3 framework on Polygon. The Problem: The Post-Hard Fork RPC Latency Wall 🐛 During heavy network volume spikes or directly following major ledger upgrades, our automated event listener logging pipeline kept crashing with random, non-deterministic invalid block range exceptions when attempting to pull historical data blocks via standard eth_getLogs routines. The Technical Root Cause The root bottleneck came down to an internal desync inside shared public RPC telemetry environments: The Bor Layer mints new block headers at a blistering speed (~2 seconds). The Internal Indexer DB takes slightly longer to completely unpack, parse, and commit transaction event logs to disk. When our asynchronous scripts called the node, latest grabbed the bleeding edge tip of the chain from memory, but a simultaneous getLogs query hit the slower indexer database. This split-millisecond race condition threw immediate pipeline errors. The Fix: Layered Application Buffering 🛠️ To smash this bug without modifying low-level node client builds, we engineered a programmatic block-padding delay loop directly into our interaction routers. Instead of tracking unfinalized tip block states blindly, we forced our queries to target safe block ranges sitting securely just behind the tip of the chain. // Localized block-buffer deployment fix const currentChainTip = await provider . getBlockNumber (); const indexedBlockBoundary = currentChainTip - 3 ; // Buffer 3 blocks (~6 second safety zone) const targetLogs = await contract . getLogs ({ fromBlock : indexedBlockBoundary - 20 , toBlock : indexedBlockBoundary }); This structural adjustment completely stabilized our off-chain reward data pipeline, gua

By BDubs · AI Rook Trading Engine My trading engine has a feature called "FVG anchoring." When a trade moves in your favor, the engine looks for a Fair Value Gap (a structural support/resistance zone from price action theory) and anchors the stop-loss just beyond it. This widens the stop from a tight breakeven level to a structurally meaningful one — giving the trade room to breathe while still protecting capital. It worked great for long trades. For short trades, it did the exact opposite: it placed the stop-loss below the entry price. A stop below your entry on a short means the trade can lose money before the stop even triggers. Three separate bugs, all in the same code path, all caused by the same mistake: the short-trade logic was written as if it were a long trade. The Context The Rook Engine manages trade exits in phases. Phase 1 is the initial breakeven guard. Phase 2 tries to anchor the stop to a reverse FVG. Phase 3 switches to trailing. The FVG anchoring code lives across two files: fvg-detector.js (finds the FVG) and exit-manager.js (uses it to set the stop). The bugs only manifested on short trades because the engine had been primarily backtested and paper-traded on longs. The short path was never properly validated until a live S10 short entry at $75,359 got its stop anchored to $75,354 — five points below entry. The trade was stopped out immediately. Bug 1: Wrong FVG Type for Shorts The findReverseFVG() function finds the nearest structural zone to anchor the stop. For longs, you want a bearish FVG above price (resistance). For shorts, you want… also a bearish FVG above price (resistance). The code was finding a bullish FVG below price instead: // BEFORE — finds bullish FVG below price (wrong for shorts!) const candidates = active . filter ( f => f . type === ' bullish ' && f . top < currentPrice ) . sort (( a , b ) => b . top - a . top ); A bullish FVG below price is a support zone. Placing a stop just above support when you're short is like placing

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . I spent a week deploying a CrewAI agent to AWS Bedrock AgentCore. The SDK wasn't on PyPI. The error messages were 200 OKs. The container crashed without logs. And the naming regex rejected hyphens without telling me why. This is the full debugging trail. Every failure was silent. Every fix required reading source code nobody documented. Table of Contents The Project Failure 1: The SDK That Doesn't Exist on PyPI Failure 2: The 200 OK That Means Failure Failure 3: The Container That Crashed With No Logs Failure 4: The Naming Regex Nobody Documented The Two-Client Split Nobody Mentions What I Learned The project I built a resume-tailoring AI agent with CrewAI and Amazon Bedrock. It takes a job description, analyzes your resume, identifies gaps, and rewrites bullet points to match what the role actually needs. Locally it worked perfectly. CrewAI orchestrates the agents, Bedrock Nova Pro handles the LLM calls, and the output is solid. Deploying it to production was the problem. AWS launched Bedrock AgentCore in June 2026 as a managed runtime for AI agents. You containerize your agent, push the image, and AgentCore handles scaling, memory, and invocation. Sounds simple. It was not simple. Failure 1: The SDK that doesn't exist on PyPI The docs say to install bedrock-agentcore-client . I ran: pip install bedrock-agentcore-client It installed successfully. No errors. That's because there's a placeholder package on PyPI with that name. It installs, imports fail silently, and your container builds successfully with a broken dependency inside. The real SDK lives in AWS's CodeArtifact registry. You need to configure pip to pull from a private index: aws codeartifact login --tool pip \ --domain amazon-agent-runtimes \ --repository agent-runtimes-pypi \ --domain-owner 600427722194 Then install from there. The PyPI package is a trap. Nobody warns you. Hours lost: 3. The error only appears at runtime

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . 🎭 The Recurring Villain If you've built WordPress sites long enough, you know this bug. It doesn't show up as an error in your console. It doesn't throw a fatal exception. It just quietly sits there, page after page, client after client — and it's called video bloat . Nine years into web development, I lost count of how many times a client sent me a site with a message like "it's just... slow." And nine times out of ten, when I opened DevTools and checked the waterfall, the story was the same: three, four, sometimes ten embedded YouTube videos, each one dragging in its own iframe, its own set of scripts, its own chunk of megabytes — all loading the second the page rendered, whether the visitor scrolled past them or not. One video embed alone can pull in 500KB–1MB+ before a user even presses play. Multiply that by a landing page stacked with testimonials, product demos, and a hero video, and you've got a page that fights your Core Web Vitals before it's even finished loading. 🔁 The Manual Fix (Every. Single. Time.) For years, my solution was the same tedious ritual: Find every video embed on the page. Replace the iframe with a static thumbnail image. Write a bit of custom JavaScript to swap the thumbnail for the real embed on click or scroll. Repeat it for YouTube. Repeat it again for Vimeo, because Vimeo's oEmbed API works differently. Repeat it again for self-hosted <video> tags, because now you're dealing with <source> tags instead of iframes. Test it across whatever page builder the client was using — Elementor, Divi, WPBakery, or straight-up Gutenberg blocks — because every one of them nests the video markup slightly differently. It worked. But it was never reusable. Every project meant writing the lazy-load script again, half from memory, half copy-pasted from my own old projects, tweaked just enough to fit the new theme's markup. It was the same bug, wearing a different site's c

Two critical security flaws in WordPress’ software have given hackers the chance to remotely take over tens of millions of websites, according to an estimate by a cybersecurity researcher.