Skip to content

Audit obfuscated server retry behavior against eMuleAI repeat-login fix

Workflow status is tracked in GitHub: https://github.com/emulebb/emulebb/issues/30. This local document is retained as an engineering spec/evidence record.

Summary

eMuleAI release notes mention fixes for repeated obfuscated server-login attempts and related connection behavior. eMuleBB already has conservative server crypto-flag handling and prior obfuscated-server fixes, but the exact retry path does not obviously match eMuleAI's behavior. This item records the remaining audit so it does not get lost.

eMuleAI Implementation Reference

Review source: eMuleAI commit 8e34bdec2b7e4fe9e4307df9d80f691804be99ed.

Current Risk

The likely user-visible failure is not data loss. It is connectivity friction: some obfuscated servers may require an extra or different retry path before falling back to plain connection or another server. Because retry behavior can also create network drift, this must be audited before porting.

Intended Fix Shape

  • Compare current eMuleBB ServerConnect behavior against community baseline and eMuleAI for obfuscated and plain server paths.
  • Reproduce a failing server-login scenario before changing behavior.
  • If a real defect exists, port only the smallest retry-state correction and preserve existing logs.

Acceptance Criteria

  • [x] a deterministic or live repro identifies the retry gap
  • [x] disabled/unsupported obfuscation still falls back exactly as expected
  • [x] no broad server-list scheduling policy changes are bundled
  • [x] logs identify which retry path was used

Closure Evidence

Closed on 2026-05-24 by porting the narrow eMuleAI repeated-login guard: duplicate automatic ConnectToServer requests are suppressed while the same server is already awaiting login, while explicit web/manual connects can still request a fresh attempt. The obfuscated single-server fallback and timeout paths were routed through a tested seam and now emit debug log lines identifying the selected retry path.

The audit compared current ServerConnect and ServerSocket behavior against the local eMuleAI reference. The actionable delta was the duplicate pending server guard (AwaitingConnectionToServer) and the explicit manual web-connect bypass; eMuleBB does not currently expose eMuleAI's RepeatServerList preference, so no broad list-repeat policy was bundled.

Validation:

  • python -m emule_workspace validate
  • python -m emule_workspace build app --variant main --config Debug --platform x64 --build-output-mode ErrorsOnly
  • python -m emule_workspace build app --variant main --config Release --platform x64 --build-output-mode ErrorsOnly
  • python -m emule_workspace build tests --config Debug --platform x64 --build-output-mode ErrorsOnly
  • python -m emule_workspace build tests --config Release --platform x64 --build-output-mode ErrorsOnly
  • python -m emule_workspace test native --config Debug --platform x64 --suite-name server_connect --build-output-mode ErrorsOnly
  • python -m emule_workspace test native --config Release --platform x64 --suite-name server_connect --build-output-mode ErrorsOnly
  • python -m emule_workspace test native --config Debug --platform x64 --suite-name parity --build-output-mode ErrorsOnly
  • python -m emule_workspace test native --config Release --platform x64 --suite-name parity --build-output-mode ErrorsOnly