Skip to content

report an unexpected Telnet send failure instead of dropping the client - #331

Merged
FreeAndNil merged 2 commits into
masterfrom
Feature/331-telnet-send-failure
Sep 28, 2026
Merged

FreeAndNil merged 2 commits into
masterfrom
Feature/331-telnet-send-failure

Conversation

@FreeAndNil

Copy link
Copy Markdown
Contributor

Every throw from a Telnet write was read as a dead client, so a bug in what we write dropped every
client, one per event. That was f013.

Only SocketException, IOException and ObjectDisposedException disconnect now. The rest is
rethrown after the loop and reported by BackgroundSender.

Commit 2, test-only:

  • AdoNetAppenderTest twice, XmlConfiguratorTest, LogLogTest, StringFormatTest once each
  • ten provoked log4net:ERROR off stderr, two left, asserted by LogLogTest
  • CLAUDE.md gets the ReflectionExtensions convention from one home for the reflection in the tests #326

#331

SocketHandler.Send read every non-fatal exception as a hung up connection, so a
defect in what we write cost every client in turn. That is how f013 became a
mass disconnect.

* Only SocketException, IOException and ObjectDisposedException disconnect.
  Anything else is raised after the loop and reported by BackgroundSender.
* SocketHandler is protected, so a subclass calling Send sees exceptions it
  did not before.
Five tests provoked log4net:ERROR or WARN on purpose and let it reach stderr.

* AdoNetAppenderTest twice, XmlConfiguratorTest, LogLogTest and
  StringFormatTest once each.
* Ten messages down to two. The two left are LogLogTest.EmitInternalMessages,
  which asserts the console output itself.
@FreeAndNil FreeAndNil added this to the 3.5.0 milestone Sep 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants