Skip to content

fix(connect): log exception message when rejecting session proposals - #148

Open
minekube-ai-engineer[bot] wants to merge 1 commit into
mainfrom
fix/proposal-reject-log
Open

fix(connect): log exception message when rejecting session proposals#148
minekube-ai-engineer[bot] wants to merge 1 commit into
mainfrom
fix/proposal-reject-log

Conversation

@minekube-ai-engineer

Copy link
Copy Markdown

Source: Discord ask-support thread — the exact thread the report came from.

Problem

Since 0.15.1, WatcherRegister.onProposal's rejection catch logs only the exception class name and discards e.getMessage():

Rejected one Connect session proposal (category=IllegalStateException); keeping WatchService active

Every rejected proposal therefore looks identical and the failing check is invisible — the reason #144 ("session proposals rejected with IllegalStateException") was never root-caused. This is the diagnosability defect blocking #144 and the fresh escalation from byteadri.exe (fails identically on stable Velocity 3.4.0 and 4.1.0-SNAPSHOT, so #144's SNAPSHOT-only assumption is disproven).

Change

  • WARN now includes message={} (the exception message) alongside category={} — one log line identifies the failing check.
  • Full throwable logged at DEBUG when debug mode is enabled.
  • Regression test rejectedProposalWarnCarriesTheExceptionMessage drives the real mechanism (BedrockAdmissionCoordinator.stage() → ISE "Bedrock admission has expired or been superseded") and asserts the WARN carries the message. RED on unfixed code (message absent), GREEN after.

TDD evidence

  • RED: WARN must carry the exception message, got: [Rejected one Connect session proposal (category=IllegalStateException); keeping WatchService active] ==> expected: <true> but was: <false>
  • GREEN: :core:test WatcherRegisterTest 24/24; full ./gradlew check 342/342 (velocity + core; one pre-existing environmental ReleaseAssetVerificationTest failure without jq on PATH passes with it — unrelated).

Once this ships, the user's next failed join prints the actual check that failed, which is the root cause for #144 and this escalation.

Since 0.15.1 the proposal-rejection WARN logged only the exception class
name and discarded e.getMessage(), so every rejection looked identical
(category=IllegalStateException) and the actual failing check was
invisible (connect-java#144). Log the message at WARN level and the full
throwable at DEBUG. Regression test asserts the WARN carries the
exception message for the stage() ISE path.
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.

0 participants