@steipete your commit adds html tags: 073651fb570a9ef555c44e4f1ea54b3d78d84ec2

## Sponsors
+
+<table align="center">
+  <tr>
+    <td align="center" valign="middle" bgcolor="#111827" width="240" height="72">
+      <a href="https://openai.com/" target="_blank" rel="noopener">
+        <img src="docs/assets/sponsors/openai.svg" alt="OpenAI" height="34" />
+      </a>
+    </td>
+    <td width="16"></td>
+    <td align="center" valign="middle" bgcolor="#111827" width="240" height="72">
+      <a href="https://blacksmith.sh/" target="_blank" rel="noopener">
+        <img src="docs/assets/sponsors/blacksmith.svg" alt="Blacksmith" height="34" />
+      </a>
+    </td>
+  </tr>
+</table>
+

Should we allow html tags for CI?

Thanks

@obviyus Can you please check?

Just noticed a connection:

Several other PRs seem to address the same problem:

• PR fix(msteams): prevent EADDRINUSE restart loop #20455 by @taradtke
• PR fix(msteams): prevent false auto-restart loop after successful startup #22182 by @pandego
• PR fix(msteams): resolve EADDRINUSE double-start by awaiting port binding #22184 by @harshang03

Issue #22169 reports msteams provider starting twice on gateway boot causing EADDRINUSE; PR#22182 fixes the false auto-restart loop by keeping the provider promise pending until abort.

Both approaches have merit — might be worth coordinating.

Related issue(s): #22169

If any of these links don't look right, let me know and I'll correct them.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Closing this PR as superseded by follow-up work on the same issue path.

The msteams lifecycle fix is covered in #22182, so I am closing this one to keep the queue clean and avoid duplicate maintenance.

Thanks everyone for the review context and cross-links.

Field report from a live production recovery (sanitized, no secrets / no env values). Posting this in case it helps maintainers and others triaging the same restart-loop class.

Executive summary

We hit a Microsoft Teams provider auto-restart loop with the same user-visible signature described here:

• provider logs startup and directory/channel resolution
• then immediately reports auto-restart attempts (1/10, 2/10, ...)
• loop persists despite successful startup-side lookups

In our incident, there were three independent contributors. Fixing only one did not fully resolve the loop:

1. Package collision (legacy global package co-installed with current package)
2. Missing Teams bot credential field (app secret not set)
3. Upstream lifecycle bug pattern (provider promise appears to resolve too early, matching this issue family)

What we observed (timeline-style)

Phase A — restart loop with repeated startup success signals

• Teams provider repeatedly logged startup, user resolution, and channel resolution.
• Immediately after these success logs, gateway health/auto-restart kicked in.
• Backoff pattern matched known restart-loop behavior.

Phase B — eliminated local package-collision factor

• Found old global package and current package both installed.
• Removed legacy global package.
• Result: removed one clear conflict vector, but loop still present.

Phase C — fixed missing credential config

• Added missing Teams bot app password field (client secret value) in channel config.
• Triggered config reload / gateway restart.
• Result: credential state improved, but restart loop still present.

Phase D — remaining behavior matches known monitor/lifecycle bug class

• Even after cleanup + credentials corrected, pattern remained:
  • start provider
  • resolve users/channels
  • immediate auto-restart
• This aligns with issue reports where monitor/start function resolves prematurely and channel manager interprets that as provider exit.

Distinguishing signals that helped triage

These indicators were the most useful to separate local misconfiguration from upstream bug behavior:

1. Success-before-failure pattern

   • If user/group/channel resolution consistently succeeds before restart, network/auth may not be the primary blocker.

2. Stable repeating loop shape

   • Consistent startup → resolution → restart sequence with backoff strongly suggests lifecycle contract mismatch.

3. Persistence across remediation layers

   • If loop persists after:
     • removing duplicate installs,
     • setting required credentials,
     • clean restart,
       then upstream monitor lifecycle is likely involved.

Secure remediation checklist that worked best for us

(Generalized to avoid host-specific details)

1) Eliminate package duplication first

• Verify only one canonical global installation is active.
• Remove legacy/conflicting package names that may still register plugins.
• Re-check plugin load path consistency.

2) Validate Teams auth fields completely

• Ensure app ID, tenant ID, and app password (client secret value) are all present.
• Confirm config validation passes before restart.

3) Restart and verify by behavior, not process state

• Don’t trust “running” status alone.
• Verify no new auto-restart attempt lines over a timed observation window.
• Verify inbound/outbound Teams flow during that same window.

4) If still looping, classify as likely upstream lifecycle bug

• Capture exact log sequence around each restart boundary.
• Attach sanitized sequence to issue/PR for maintainers.

What to include in repro data (high value for maintainers)

Recommend sharing these artifacts (all sanitized):

• startup line for msteams provider
• user/group/channel resolution lines
• first line indicating restart scheduling
• health-monitor line indicating “reason: stopped” (if present)
• whether duplicate package installations were found
• whether credentials were complete at time of test
• whether loop persists after those are corrected

Suggested maintainer-facing acceptance test

A robust guardrail test for this bug class would assert:

1. startAccount() for Teams does not resolve while provider is healthy.
2. Resolver success (users/channels) alone does not trigger subsystem restart logic.
3. Restart path only activates on explicit stop, fatal error, or abort signal.
4. No duplicate listener bind occurs during healthy run (prevents EADDRINUSE cascades).

Current status from this field report

• Local config/package hygiene issues: addressed.
• Remaining loop signature: still consistent with upstream lifecycle bug described in this issue family.
• Net: this report supports merging a monitor/start lifecycle fix that keeps provider task pending until true shutdown.

If helpful, I can provide a compact sanitized log excerpt in follow-up showing exact line ordering (startup → resolution → restart) without any identifiers.

Superseded by already-merged MSTeams lifecycle work:

• fix(msteams): keep monitor alive until shutdown #24580
• fix(security): harden msteams webhook ingress timeouts #25960

The provider lifecycle now stays pending until abort/shutdown, with monitor lifecycle regression coverage in main. This addresses the same restart-loop root cause.

Closing as duplicate/superseded to keep the queue focused. Thank you for the thorough write-up and docs context.