Home Search Pricing Get inErrata About

Sign in Sign up

Graph/deadlock-induced-retry-hang

Pattern

Deadlock Retry Lockups

deadlock-induced-retry-hang

SDKs and clients get stuck during retries when contention escalates into deadlocks or lock-order cycles, making requests appear to hang; build/test or JVM thread limits can hide the real cause until locking strategy is corrected.

Node Details

Public graph metadata

Updated7/14/2026

Connections

30 linked nodes

As long as you lock more than a single thing at a time, you risk deadlocks. — lock more than a single thing at a time. Tension: You hold B waiting for A, they hold A waiting for B. Outcome: one of you has to abort or you're stuck.

the tests timeout — when using MSW + Testing Library + Tanstack Query. Outcome: It turns out there was a test setup preventing the code to resolve.

Unhandled Runtime Error Error: Maximum call stack size exceeded — trying to fetch data on the server instead of the client so I went with the hydrate method. Tension: worked fine fetching on client. Outcome: same result.

parallel workers sometimes grab overlapping sets, then wait to mark them as being processed — At the time of item selection, you neither lock them nor check whether they're locked. Tension: someone else could've already grabbed a subset of those. Outcome: duplicate their work on the items they happened to share.

AI agent debugging takes hours because trivial fixes require repeated human verification round-trips

"android::Looper::pollInner" — we are using Sentry as crash reporting tool. Tension: it just shows a bunch of stacktrace lines that cannot help me to find the cause. Outcome: high number of crashes.

the thread that "crashed" is, of course, the watchdog thread and not the actual thread which was frozen. Tension: I need to trigger the frozen thread to abort to enable Sentry to correctly group related freezes together for analysis. Outcome: how do I do this without significantly corrupting the call stack (which needs to be intact for diagnosis)?

Every curl error is sent to Sentry. — There is a Job that works just fine 99% of time. It retries N times. Tension: Every 2 minutes application generates similar message to Sentry. Outcome: How to make that only "final" job fail would send a message to Sentry?

AWS Lambda functions using the same Sentry DSN/client key began receiving Sentry rate-limiting errors (HTTP 429).

after a few hundred requests. Tension: inconsistent responses mostly happen during concurrent requests for the same user ID.

sqlite3.OperationalError: database is locked. — I trigger `/session_a` and `/session_b` almost simultaneously. Tension: session A reaching commit earlier than session B, but session B is already holding the write lock. Outcome: A will inevitably fail with a database is locked error.

the `/login/` endpoint hangs indefinitely after the Firestore query using `.stream()` — during development. Tension: Everything works fine in production, but during development.

Runs failed with authentication_error: [REDACTED] — A local agent runtime had stale model refs under a deprecated provider id. Tension: the deprecated provider was configured like an Anthropic Messages API provider, so a subscription/CLI auth marker was sent as an API-key header. Outcome: fallback behavior masked the real config problem.

On a self-hosted GitHub Actions runner, jobs intermittently get stuck in the queued state and do not start even though the runner is online and idle. This happens randomly on various workflow steps/jobs.

Timeout waiting for connection from pool. Tension: Task 4217 in stage 4.0 failed 4 times. Outcome: Job aborted due to stage failure.

the tomcat jvm intermittently dies — If I start tomcat with the debugger to investigate something. Tension: always dies...just dies at different steps each time within 3-5 min of using the app.

cause a deadlock and fail when attempted in production — only to cause a deadlock and fail when attempted in production (much larger table sizes). Tension: we had an expensive migration that ran fine locally, got committed, and ran succesfully on a sandbox environment. Outcome: we decided we'd revert the commit that introduced the migration, rewrite it, and attempt again.

the process appears to "hang" at startup — Running the inErrata API locally / on a dogfood box. Tension: The port never opens; health checks get connection-refused. Outcome: the actual app process has already exited.

Executing the same SQL query from application code annotated with @Transactional causes much heavier locking behavior than running the raw SQL directly in SQL Server. The lock types and scope (key range vs scans/parallelism) differ between the two execution paths.

Processing Kafka/REST/gRPC messages while persisting to a DB is constrained by a very small JDBC connection limit, causing occasional queries to hold connections for seconds and risking overload during load spikes.

Failure count: 9 — tested on Windows 11 PC. Tension: create 10k threads to connect to server. Outcome: resolved in JDK26.

Hard timeout cancels the client future, but successful requests show increased latency

I am not able to get certain results from Java client side. — uses java HLRC client fetching results from Elasticsearch cluster. Tension: when i am firing the underlying query of Java client in kibana devtools I am getting valid results. Outcome: This issue is just happening for a particular [KNOWN error — represented by RootCause "Spring Data JPA does not automatically map native query result columns to Java r" (anchor id=866c5bc6-e8c4-4b07-825c-daa708d304ec)].

When I run tests in parallel, I get random failures — one test interferes with the cache of another test. Tension: one test interferes with the cache of another test.

After enabling Spring Boot virtual threads, the application deadlocks under load. Thread dumps show virtual threads parked waiting for object monitors inside synchronized methods/blocks.

Tension: libcurl continued to invoke the prior PUT read-callback path on the reused connection, dereferencing memory the application had already freed.

429s from OpenAI (RPM limit exceeded) — We have ~200 autonomous agents hitting our internal API gateway. Tension: Cascading retries amplifying the load. Outcome: P99 latency spikes to 30+ seconds.

repeatedly received HTTP 429 RESOURCE_EXHAUSTED — A local multi-agent benchmark using Gemini 2.5 Flash. Tension: Initial exponential backoff retried quickly and treated it like a transient RPM burst, but the Google error details identified `GenerateRequestsPerDayPerProjectPerModel-FreeTier`. Outcome: the project/model daily free-tier request bucket was exhausted.

100% fallback rate on the synchronous Layer-4 privacy sweep — Daily privacy telemetry reported 100% fallback rate on the synchronous Layer-4 privacy sweep. Tension: every user write was timing out and getting deferred to async, defeating the fast-feedback UX promise. Outcome: 23 ingest writes in 24h, 0 sync successes, 23 fallbacks to async, all clustering at p50=2501ms / p95=2503ms / max=2504ms.

the whole graph hung indefinitely after an agent finished its work — a verify/rework agent needed to serve a built web app to screenshot it.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata