Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

flaky: SocketIntegrationTests.testFlushedQueuedStoreAlsoPushesChannelNotification times out in CI (2 occurrences)

Open
  • Is something wrong?
#891 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
50/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
swift
Domain
networking, testing-qa

Research direction

Start in brain-bar/Tests/BrainBarTests/SocketIntegrationTests.swift around the test at line 1615 and its deadline-based poll loop near line 1600. Instrument the MCP socket notification delivery on macos-15 CI to distinguish runner slowness from a lost notification. Done means the cause is established and the separate PR either fixes the notification race or documents and justifies a timing change.

Written by the indexing model from the issue text.

Description

bug

Two independent occurrences, same assertion, unrelated diffs

run head branch duration date (UTC)
34973638999 ae64a313 main (#879 merge) 6.087 s 2026-09-15T13:13:35Z
104464310365 a2eae30a #890 6.472 s 2026-09-15 ~17:0xZ

Both fail identically:

brain-bar/Tests/BrainBarTests/SocketIntegrationTests.swift:1615: error:
  -[BrainBarTests.SocketIntegrationTests testFlushedQueuedStoreAlsoPushesChannelNotification]
  : failed: caught error: "Error Domain=test Code=4 "Timeout reading response""

It is not caused by either diff

#890 is metadata only — 4 files, 7 lines, all version strings (pyproject.toml, src/brainlayer/__init__.py, server.json, brain-bar/bundle/Info.plist). grep -rn "server\.json" src/ brain-bar/Sources/ returns nothing, so no runtime code reads the one manifest whose content changed. A version string cannot time out a socket read.

The main occurrence at ae64a313 predates #890 entirely.

Why this is worth fixing rather than rerunning

The failure is a wall-clock deadline in a poll loop (Thread.sleep(0.01) until a deadline, SocketIntegrationTests.swift:~1600-1615). On a loaded macos-15 runner that is timing-sensitive by construction — but the surface under test is MCP socket notification delivery, which is how every agent in this fleet reaches BrainLayer. A race there is not cosmetic, and "it passed on the rerun" does not distinguish a slow runner from a real lost notification.

A rerun-to-green makes the release gate unreliable in exactly the direction that hides a real defect. swift (macos-15) is one of the five required checks; a test that fails ~2 times in a day trains everyone to rerun it.

Asks

  1. Decide whether the timeout is runner slowness or a genuine notification race. Instrument, do not infer.
  2. If it is timing, raise the deadline and say why the new number is right — a bigger magic number chosen to stop the red is not a fix.
  3. If it is a race, it is a product bug in the notification path, not a test bug.

Pre-existing, so per canon-9 it gets its own PR; #890 must not fix it.

Dominant language
Python
Stars
9
Forks
7
Avg merge
2h 8m
Merged PRs (30d)
225

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EtanHey/brainlayer

All issues in EtanHey/brainlayer

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.