fix(msteams): surface network errors blocking bot JWT validation and outbound replies (#77674)#78081
Conversation
|
Codex review: needs changes before merge. Summary Reproducibility: yes. by source inspection. Current main catches all JWKS lookup and JWT verification failures as Real behavior proof Next step before merge Security Review findings
Review detailsBest possible solution: Keep the Teams-plugin-local fix, but make the middleware log every JWKS fetch error the validator intentionally rethrows while preserving strict 401 rejection and the new Connector network hint. Do we have a high-confidence way to reproduce the issue? Yes by source inspection. Current main catches all JWKS lookup and JWT verification failures as Is this the best way to solve the issue? No, not quite. The plugin-local direction is the narrow maintainable fix, but Full review comments:
Overall correctness: patch is incorrect Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against f35fb7288a70. |
573de2f to
50e2931
Compare
|
Maintainer prep update for #78081 / #77674:
proof: maintainer override. I reviewed the source-level behavior and targeted tests for the reported blocked-egress paths. The before/after is deterministic in code: Local verification on prepared head
Fresh CI is queued/running on the pushed head now; I will merge only after required checks are green. |
50e2931 to
f374344
Compare
|
Maintainer refresh: added |
…n and outbound replies (openclaw#77674) When login.botframework.com or smba.trafficmanager.net egress is blocked, errors previously disappeared completely. JWT validator swallowed network errors and returned false (401 looked identical to a bad credential), and outbound send failures with transport-level codes had no hint pointing to the Connector endpoint. - sdk.ts: rethrow ECONNREFUSED/ENOTFOUND/EHOSTUNREACH/ETIMEDOUT/ECONNRESET from the JWKS key fetch so callers can distinguish firewall blocks from bad credentials; add isJwksNetworkError() helper - monitor.ts: catch rethrown network errors in JWT middleware and log at runtime.error level with an actionable message pointing to login.botframework.com:443; upgrade allowlist resolution failures from runtime.log (optional/silent) to runtime.error - errors.ts: add "network" kind to classifyMSTeamsSendError for transport-level errors (ECONNREFUSED, ENOTFOUND, etc.); add formatMSTeamsSendErrorHint for "network" kind pointing to smba.trafficmanager.net and egress rules - monitor-handler.ts, message-handler.ts: remove spurious ?. from runtime.error calls (RuntimeEnv.error is a required non-optional field) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
f374344 to
ad42d65
Compare
|
Maintainer refresh: rebased onto current main after #77907 landed and pushed prepared head |
…outbound replies (openclaw#77674) (openclaw#78081) * fix(msteams): surface network errors blocking Teams bot JWT validation and outbound replies (openclaw#77674) When login.botframework.com or smba.trafficmanager.net egress is blocked, errors previously disappeared completely. JWT validator swallowed network errors and returned false (401 looked identical to a bad credential), and outbound send failures with transport-level codes had no hint pointing to the Connector endpoint. - sdk.ts: rethrow ECONNREFUSED/ENOTFOUND/EHOSTUNREACH/ETIMEDOUT/ECONNRESET from the JWKS key fetch so callers can distinguish firewall blocks from bad credentials; add isJwksNetworkError() helper - monitor.ts: catch rethrown network errors in JWT middleware and log at runtime.error level with an actionable message pointing to login.botframework.com:443; upgrade allowlist resolution failures from runtime.log (optional/silent) to runtime.error - errors.ts: add "network" kind to classifyMSTeamsSendError for transport-level errors (ECONNREFUSED, ENOTFOUND, etc.); add formatMSTeamsSendErrorHint for "network" kind pointing to smba.trafficmanager.net and egress rules - monitor-handler.ts, message-handler.ts: remove spurious ?. from runtime.error calls (RuntimeEnv.error is a required non-optional field) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(msteams): surface blocked botframework egress --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Brad Groux <3053586+BradGroux@users.noreply.github.com>
Summary
sdk.ts) previously swallowed all JWKS fetch errors and returnedfalse, making firewall blocks tologin.botframework.comlook identical to a bad credential — now rethrows network errors (ECONNREFUSED,ENOTFOUND, etc.) so the JWT middleware can log them atruntime.errorlevel with an actionable message pointing to the blocked hosterrors.ts: new"network"kind inclassifyMSTeamsSendErrorfor transport-level failures;formatMSTeamsSendErrorHintnow returns a hint pointing tosmba.trafficmanager.netand egress firewall rules for network errorsmonitor.ts: allowlist resolution failures upgraded from optionalruntime.log?.(silent if hook absent) toruntime.error(always logged); JWKS network errors caught separately and logged at error levelmonitor-handler.ts,message-handler.ts: remove spurious?.fromruntime.errorcalls (RuntimeEnv.erroris a required field, the optional chaining was silently discarding handler failures when the runtime wrapper had an unexpected shape)Closes #77674
Testing
Real behavior proof
login.botframework.comorsmba.trafficmanager.netare blocked — errors are swallowed and logs don't help distinguish firewall block from bad credentialsproof:override or advise on evidence format.