## Issue Addressed

Fix a deadlock introduced in #4236 which was caught during the v4.4.0 release testing cycle (with thanks to @paulhauner and `gdb`).

## Proposed Changes

Avoid re-locking the fork choice read lock when querying a state by root in the HTTP API. This avoids a deadlock due to the lock already being held.

## Additional Info

The [RwLock docs](https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html#method.read) explicitly advise against re-locking:

> Note that attempts to recursively acquire a read lock on a RwLock when the current thread already holds one may result in a deadlock.

## Proposed Changes

New release to replace the cancelled v4.4.0 release.

This release includes the bugfix #4687 which avoids a deadlock that was present in v4.4.0.

## Additional Info

Awaiting testing over the weekend this will be merged Monday September 4th.

…4688)

## Issue Addressed

I went through the code base and look for places where we acquire fork choice locks (after the deadlock bug was found and fixed in #4687), and discovered an instance where we re-acquire a lock immediately after dropping it. This shouldn't cause deadlock like the other issue, but is slightly less efficient.

…4688)

## Issue Addressed

I went through the code base and look for places where we acquire fork choice locks (after the deadlock bug was found and fixed in #4687), and discovered an instance where we re-acquire a lock immediately after dropping it. This shouldn't cause deadlock like the other issue, but is slightly less efficient.

…4688)

## Issue Addressed

I went through the code base and look for places where we acquire fork choice locks (after the deadlock bug was found and fixed in #4687), and discovered an instance where we re-acquire a lock immediately after dropping it. This shouldn't cause deadlock like the other issue, but is slightly less efficient.

…4688)

## Issue Addressed

I went through the code base and look for places where we acquire fork choice locks (after the deadlock bug was found and fixed in #4687), and discovered an instance where we re-acquire a lock immediately after dropping it. This shouldn't cause deadlock like the other issue, but is slightly less efficient.

…4688)

## Issue Addressed

I went through the code base and look for places where we acquire fork choice locks (after the deadlock bug was found and fixed in #4687), and discovered an instance where we re-acquire a lock immediately after dropping it. This shouldn't cause deadlock like the other issue, but is slightly less efficient.

…4688)

## Issue Addressed

I went through the code base and look for places where we acquire fork choice locks (after the deadlock bug was found and fixed in #4687), and discovered an instance where we re-acquire a lock immediately after dropping it. This shouldn't cause deadlock like the other issue, but is slightly less efficient.

…igp#4688)

## Issue Addressed

I went through the code base and look for places where we acquire fork choice locks (after the deadlock bug was found and fixed in sigp#4687), and discovered an instance where we re-acquire a lock immediately after dropping it. This shouldn't cause deadlock like the other issue, but is slightly less efficient.

## Issue Addressed

Fix a deadlock introduced in sigp#4236 which was caught during the v4.4.0 release testing cycle (with thanks to @paulhauner and `gdb`).

## Proposed Changes

Avoid re-locking the fork choice read lock when querying a state by root in the HTTP API. This avoids a deadlock due to the lock already being held.

## Additional Info

The [RwLock docs](https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html#method.read) explicitly advise against re-locking:

> Note that attempts to recursively acquire a read lock on a RwLock when the current thread already holds one may result in a deadlock.

New release to replace the cancelled v4.4.0 release.

This release includes the bugfix sigp#4687 which avoids a deadlock that was present in v4.4.0.

Awaiting testing over the weekend this will be merged Monday September 4th.

## Issue Addressed

Fix a deadlock introduced in sigp#4236 which was caught during the v4.4.0 release testing cycle (with thanks to @paulhauner and `gdb`).

## Proposed Changes

Avoid re-locking the fork choice read lock when querying a state by root in the HTTP API. This avoids a deadlock due to the lock already being held.

## Additional Info

The [RwLock docs](https://docs.rs/lock_api/latest/lock_api/struct.RwLock.html#method.read) explicitly advise against re-locking:

> Note that attempts to recursively acquire a read lock on a RwLock when the current thread already holds one may result in a deadlock.

New release to replace the cancelled v4.4.0 release.

This release includes the bugfix sigp#4687 which avoids a deadlock that was present in v4.4.0.

Awaiting testing over the weekend this will be merged Monday September 4th.