Skip to content

Add v3.0.2 release notes#3276

Merged
jlowin merged 1 commit intomainfrom
docs/release-notes-3.0.1-3.0.2
Feb 22, 2026
Merged

Add v3.0.2 release notes#3276
jlowin merged 1 commit intomainfrom
docs/release-notes-3.0.1-3.0.2

Conversation

@jlowin
Copy link
Copy Markdown
Member

@jlowin jlowin commented Feb 22, 2026

Adds the v3.0.2 "Threecovery Mode II" entry to both updates.mdx and changelog.mdx.

@marvin-context-protocol marvin-context-protocol Bot added the documentation Updates to docs, examples, or guides. Primary change is documentation-related. label Feb 22, 2026
@jlowin jlowin merged commit e19f239 into main Feb 22, 2026
9 of 10 checks passed
@jlowin jlowin deleted the docs/release-notes-3.0.1-3.0.2 branch February 22, 2026 16:41
@marvin-context-protocol
Copy link
Copy Markdown
Contributor

Test Failure Analysis

Summary: A single timing-sensitive test failed on the Python 3.10 Ubuntu runner due to CI scheduling jitter. The PR changes (documentation only) are unrelated to the failure.

Root Cause: `tests/server/middleware/test_ping.py::TestPingLoop::test_ping_loop_sends_pings_at_interval` is a flaky test that relies on precise sub-second async scheduling. The test runs a ping loop with a 50ms interval for 350ms and asserts at least 2 pings are sent. On a loaded CI runner, `anyio.sleep(0.05)` can be delayed significantly by the scheduler, resulting in only 1 ping completing before the 350ms deadline.

The ping loop implementation (`ping.py:63-70`) sleeps before sending the first ping:
```python
while True:
await anyio.sleep(self.interval_ms / 1000) # sleep first
await session.send_ping() # then ping
```

With 350ms window ÷ 50ms interval = ~7x ratio, this should theoretically yield ~6 pings — but under scheduler pressure, even a single sleep can exhaust the window.

Suggested Solution: Increase the observation window in `tests/server/middleware/test_ping.py:172` relative to the interval to give more headroom for CI scheduling jitter. For example, change the window from `0.35` to `0.5` seconds (10x the interval), which provides enough buffer for typical CI delays while still verifying the looping behavior:

```python

Before

with anyio.move_on_after(0.35): # 7x the 50ms interval
await middleware._ping_loop(mock_session, session_id)
assert mock_session.send_ping.call_count >= 2

After

with anyio.move_on_after(0.5): # 10x the 50ms interval
await middleware._ping_loop(mock_session, session_id)
assert mock_session.send_ping.call_count >= 2
```

Detailed Analysis

Failing log excerpt:
```
E AssertionError: assert 1 >= 2
E + where 1 = .call_count
tests/server/middleware/test_ping.py:176: AssertionError
```

Test code (`tests/server/middleware/test_ping.py:161-176`):
```python
async def test_ping_loop_sends_pings_at_interval(self):
middleware = PingMiddleware(interval_ms=50)
mock_session = MagicMock()
mock_session.send_ping = AsyncMock()
session_id = id(mock_session)
middleware._active_sessions.add(session_id)

with anyio.move_on_after(0.35):
    await middleware._ping_loop(mock_session, session_id)

# Should have sent at least 2 pings in 350ms with 50ms interval
assert mock_session.send_ping.call_count >= 2

```

The failure occurred only on the `Tests: Python 3.10 on ubuntu-latest` job (job ID 64451539437). All other jobs passed (Python 3.13 ubuntu, Python 3.10 windows, lowest-direct, integration tests).

This is a pre-existing flakiness issue unrelated to the PR's documentation changes.

Related Files
  • `tests/server/middleware/test_ping.py:161-176` — The failing test
  • `src/fastmcp/server/middleware/ping.py:63-70` — The `_ping_loop` implementation that sleeps before each ping

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Updates to docs, examples, or guides. Primary change is documentation-related.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant