Aspectrr/linkedin connect new

[aspectrr]

No description provided.

[Copilot]

Pull request overview

Adds an MCP “notifications” feature intended to let clients subscribe to linkedin://notifications and receive push updates when a background poller detects new LinkedIn messages or connection approvals.

Changes:

• Introduces an MCP notifications resource plus subscribe_notifications / unsubscribe_notifications tools.
• Adds a background poller with persisted “already seen” state and a session registry that sends ResourceUpdatedNotification.
• Extends the scraper/extractor with helper methods to poll inbox thread IDs and detect connection-approval notification snippets.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
linkedin_mcp_server/tools/notifications.py	Defines MCP resource + subscribe/unsubscribe tools for notification delivery.
linkedin_mcp_server/scraping/extractor.py	Adds polling helpers (thread IDs + connection approval snippets) and broadens “More” button selector strategy.
linkedin_mcp_server/scraper_lock.py	Introduces a purportedly shared asyncio lock for poller/tool serialization.
linkedin_mcp_server/notifications/poller.py	Implements the background polling loop that should push updates to subscribed sessions.
linkedin_mcp_server/notifications/registry.py	Stores subscribed sessions + pending events; sends ResourceUpdatedNotification to sessions.
linkedin_mcp_server/notifications/state.py	Persists “seen” notification state to disk for deduping.
linkedin_mcp_server/notifications/init.py	Package marker for notifications subsystem.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

register_notification_tools() is defined here but it isn’t registered anywhere in the server setup, so the notifications resource/tools won’t be exposed at runtime. Wire this into the central tool-registration path (e.g., the MCP server factory) so clients can actually call subscribe_notifications() / read linkedin://notifications.

[Copilot]

This file is intended to provide a shared lock with SequentialToolExecutionMiddleware, but the middleware currently uses its own private asyncio.Lock() and never calls get_scraper_lock(). As a result, the poller can still run concurrently with tool calls and race the shared browser/page; either update the middleware to use get_scraper_lock() or remove/adjust this module/docstring so the actual locking behavior matches the intent.

Suggested change

	"""Shared asyncio lock for serializing all browser operations.
	Both SequentialToolExecutionMiddleware and the notification poller import this
	module so they contend on the same lock, preventing concurrent browser use.
	"""Shared asyncio lock for serializing browser operations.
	This module exposes a process-wide asyncio.Lock via get_scraper_lock(). Any
	component that needs to prevent concurrent use of the shared browser/page
	should import this module and acquire the lock around its operations.

[Copilot]

save_state() writes the on-disk notification state with Path.write_text(), which can leave the file with overly-permissive permissions and is not an atomic write. Since this state may contain sensitive message thread IDs / notification text, use the existing secure_write_text(..., mode=0o600) helper (and secure_mkdir) to ensure owner-only permissions and atomic updates.

[Copilot]

notify_all() / the linkedin://notifications resource uses a single global _pending_events queue that is drained on read. With multiple subscribed sessions, whichever client reads first will consume events for all other clients, even though they also received ResourceUpdatedNotification. Consider making the pending queue per-session (or per-subscriber cursor) so event delivery is consistent for multiple MCP clients.

Suggested change

	"""Return all pending events and clear the queue."""
	events = list(_pending_events)
	_pending_events.clear()
	return events
	"""Return a snapshot of all pending events without clearing the queue."""
	return list(_pending_events)

[Copilot]

notification_poller() is defined but not started anywhere (no references found), so no background polling/notifications will occur. Start it during the server lifespan (create an asyncio task) and ensure it is cancelled/awaited during shutdown to avoid orphaned tasks.

[Copilot]

The poll loop sleeps before doing the first poll, and CancelledError raised during that initial sleep won’t be caught/logged by the current try/except (since it begins after the sleep). Consider polling immediately on startup and wrapping the sleep inside the try so cancellation is handled consistently.

[Copilot]

get_inbox_thread_ids() doesn’t call handle_modal_close() (unlike get_inbox() and other messaging flows). If a modal is present, the JS click loop may not navigate, producing empty/missing thread IDs. Align this method with get_inbox() by closing modals (and consider doing the same minimal scrolling used in get_inbox() if you want limit > currently-rendered items).

Suggested change

	await self._wait_for_main_text(log_context="Messaging inbox")
	await self._wait_for_main_text(log_context="Messaging inbox")
	await handle_modal_close(self._page)
	# Mirror get_inbox(): perform minimal scrolling so enough
	# conversations are rendered for the requested limit.
	scrolls = max(1, limit // 10)
	await self._scroll_main_scrollable_region(
	position="bottom", attempts=scrolls, pause_time=0.5
	)

[Copilot]

New notification polling / registry / persistence code is being introduced without any tests. Since the repo has substantial pytest coverage (e.g. tests/test_tools.py, tests/test_server.py), please add tests that cover: state load/save behavior, registry drain semantics, and that the poller triggers notify_all() when new events are detected (mocking the extractor/browser).

[greptile-apps]

Greptile Summary

This PR adds a background LinkedIn notification polling system — a notifications/ package with a poller, session registry, and persistent state, plus a new scraper_lock.py for shared browser serialization, and get_inbox_thread_ids / get_connection_approval_notifications extractor methods. The feature design is reasonable in structure, but has three P1 defects that prevent it from working correctly and introduce a user-facing side effect.

Key issues:

• Notification system is dead code — register_notification_tools(mcp) is never called in server.py, and notification_poller() is never started as a background task in browser_lifespan. None of the new functionality is reachable.
• Scraper lock is not actually shared — scraper_lock.py claims that SequentialToolExecutionMiddleware and the poller share a lock, but the middleware still uses its own private self._lock. The poller can run concurrently with active tool calls, risking browser state corruption.
• get_inbox_thread_ids marks messages as read — the extractor navigates to each conversation by clicking on it inside page.evaluate, which triggers LinkedIn's read-receipt and marks up to 10 threads as read per poll cycle. It also uses a class-name-based selector (div[class*="listitem__link"]) which violates the project's scraping rules.
• Connection approval detection is English-only and fragile — matching on "accepted" / "connected" in plain text will produce false positives across other notification types and break for non-English LinkedIn locales.

Confidence Score: 2/5

Not safe to merge — the feature is entirely unwired (dead code), the browser lock guarantee is broken, and the inbox polling marks user messages as read

Three independent P1 defects: (1) neither the poller task nor the notification tools are registered in server.py so the whole feature ships as dead code; (2) the new scraper_lock module is not used by SequentialToolExecutionMiddleware so concurrent browser access is unguarded; (3) get_inbox_thread_ids clicks each conversation to extract its thread ID, which marks messages as read on every 5-minute poll cycle — an irreversible, user-visible side effect.

linkedin_mcp_server/scraping/extractor.py (side-effecting inbox method, class-name selectors), linkedin_mcp_server/scraper_lock.py (lock not shared with middleware), linkedin_mcp_server/server.py (poller task and notification tools never wired up)

Important Files Changed

Filename	Overview
linkedin_mcp_server/scraping/extractor.py	Adds get_inbox_thread_ids (marks messages as read via clicks, uses banned class selectors) and fragile English-only connection approval detection
linkedin_mcp_server/scraper_lock.py	Shared scraper lock module, but SequentialToolExecutionMiddleware still uses its own private lock — the shared-lock guarantee is broken
linkedin_mcp_server/notifications/poller.py	New background poller; never started in server lifespan, and state reload-per-cycle means save failures cause duplicate events
linkedin_mcp_server/tools/notifications.py	New MCP resource + subscribe/unsubscribe tools for notifications; well-structured but never registered in server.py
linkedin_mcp_server/notifications/registry.py	New session registry using WeakSet and module-level event queue; logic is sound but never wired up
linkedin_mcp_server/notifications/state.py	Persistent state for seen thread IDs and approval texts; straightforward JSON serialization to ~/.linkedin-mcp/
linkedin_mcp_server/notifications/init.py	Package init with module docstring; no issues

Sequence Diagram

sequenceDiagram
    participant Client as MCP Client
    participant Server as FastMCP Server
    participant Poller as notification_poller (bg task)
    participant Registry as notifications/registry.py
    participant Extractor as LinkedInExtractor
    participant State as notification-state.json

    Note over Server,Poller: ⚠️ Poller never started in browser_lifespan
    Note over Server,Registry: ⚠️ register_notification_tools never called

    Client->>Server: subscribe_notifications()
    Server->>Registry: add_session(ctx.session)
    Registry-->>Client: Subscribed

    loop Every 300s
        Poller->>Poller: asyncio.sleep(300)
        Poller->>Extractor: get_inbox_thread_ids(limit=10)
        Note over Extractor: ⚠️ Clicks each conversation (marks as read)
        Extractor-->>Poller: [thread_ids]
        Poller->>Extractor: get_connection_approval_notifications()
        Note over Extractor: ⚠️ Text-matches accepted/connected (English only)
        Extractor-->>Poller: [snippets]
        Poller->>State: load_state() / save_state()
        Poller->>Registry: add_events(events)
        Poller->>Registry: notify_all()
        Registry->>Client: ResourceUpdatedNotification
        Client->>Server: GET linkedin://notifications
        Server->>Registry: drain_events()
        Registry-->>Client: [events]
    end

Loading

Comments Outside Diff (1)

1. linkedin_mcp_server/server.py, line 49-62 (link)

   Notification system is never wired into the server

   register_notification_tools(mcp) is never called in create_mcp_server(), and notification_poller() is never started as a background task in browser_lifespan. As a result, the entire notifications module (poller.py, registry.py, state.py, tools/notifications.py) is dead code — the tools are never registered and the background poller never runs.

   Two additions are needed in server.py:

   # In browser_lifespan, start the poller task:
   from linkedin_mcp_server.notifications.poller import notification_poller
   import asyncio
   
   @lifespan
   async def browser_lifespan(app: FastMCP) -> AsyncIterator[dict[str, Any]]:
       ...
       poller_task = asyncio.create_task(notification_poller(), name="notification-poller")
       yield {}
       poller_task.cancel()
       await close_browser()

   And in create_mcp_server():

   from linkedin_mcp_server.tools.notifications import register_notification_tools
   ...
   register_notification_tools(mcp)

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: linkedin_mcp_server/server.py
   Line: 49-62
   
   Comment:
   **Notification system is never wired into the server**
   
   `register_notification_tools(mcp)` is never called in `create_mcp_server()`, and `notification_poller()` is never started as a background task in `browser_lifespan`. As a result, the entire notifications module (`poller.py`, `registry.py`, `state.py`, `tools/notifications.py`) is dead code — the tools are never registered and the background poller never runs.
   
   Two additions are needed in `server.py`:
   
   ```python
   # In browser_lifespan, start the poller task:
   from linkedin_mcp_server.notifications.poller import notification_poller
   import asyncio
   
   @lifespan
   async def browser_lifespan(app: FastMCP) -> AsyncIterator[dict[str, Any]]:
       ...
       poller_task = asyncio.create_task(notification_poller(), name="notification-poller")
       yield {}
       poller_task.cancel()
       await close_browser()
   ```
   
   And in `create_mcp_server()`:
   ```python
   from linkedin_mcp_server.tools.notifications import register_notification_tools
   ...
   register_notification_tools(mcp)
   ```
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/server.py
Line: 49-62

Comment:
**Notification system is never wired into the server**

`register_notification_tools(mcp)` is never called in `create_mcp_server()`, and `notification_poller()` is never started as a background task in `browser_lifespan`. As a result, the entire notifications module (`poller.py`, `registry.py`, `state.py`, `tools/notifications.py`) is dead code — the tools are never registered and the background poller never runs.

Two additions are needed in `server.py`:

```python
# In browser_lifespan, start the poller task:
from linkedin_mcp_server.notifications.poller import notification_poller
import asyncio

@lifespan
async def browser_lifespan(app: FastMCP) -> AsyncIterator[dict[str, Any]]:
    ...
    poller_task = asyncio.create_task(notification_poller(), name="notification-poller")
    yield {}
    poller_task.cancel()
    await close_browser()
```

And in `create_mcp_server()`:
```python
from linkedin_mcp_server.tools.notifications import register_notification_tools
...
register_notification_tools(mcp)
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraper_lock.py
Line: 1-19

Comment:
**Scraper lock not shared with `SequentialToolExecutionMiddleware`**

The module docstring states: *"Both `SequentialToolExecutionMiddleware` and the notification poller import this module so they contend on the same lock."* This is incorrect. `SequentialToolExecutionMiddleware` creates its own private lock (`self._lock = asyncio.Lock()` in `__init__`); it never calls `get_scraper_lock()`. The poller acquires `get_scraper_lock()` while tool execution is serialised by a completely different lock instance, so concurrent browser access between a running tool and the poller is not actually prevented.

To fix this, `SequentialToolExecutionMiddleware` needs to be updated to use `get_scraper_lock()` instead of its own lock:

```python
# sequential_tool_middleware.py
from linkedin_mcp_server.scraper_lock import get_scraper_lock

class SequentialToolExecutionMiddleware(Middleware):
    async def on_call_tool(self, context, call_next):
        async with get_scraper_lock():
            ...
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 2186-2193

Comment:
**Clicking conversations marks them as read on LinkedIn**

`get_inbox_thread_ids` extracts thread IDs by literally clicking each conversation item in the inbox, which triggers LinkedIn's read-receipt logic and marks messages as unread → read for the user. The background poller calls this on every cycle, silently marking up to 10 conversations as read every 5 minutes even when the user hasn't opened them.

Additionally, `div[class*="listitem__link"]` is a class-name-based selector, which violates the CLAUDE.md scraping rule: *"never class names tied to LinkedIn's layout."*

A better approach is to extract thread IDs from the `href` attributes of the `<a>` anchor elements rendered in the conversation list, without clicking:

```js
const anchors = Array.from(document.querySelectorAll(
    'main a[href*="/messaging/thread/"]'
));
const results = [];
for (let i = 0; i < Math.min(anchors.length, limit); i++) {
    const match = anchors[i].href.match(/\/messaging\/thread\/([^/?#]+)/);
    if (match) results.push({ threadId: match[1] });
}
return results;
```

This approach is non-destructive and does not rely on class names.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 2206-2229

Comment:
**Connection approval detection is English-only and prone to false positives**

`get_connection_approval_notifications` identifies connection approvals by scanning notification text for the words `"accepted"` or `"connected"`. This will:

1. Produce false positives for unrelated notifications containing these words (e.g. *"You've been accepted into a group"*, *"Your application was accepted"*).
2. Miss connection approvals entirely for users with LinkedIn set to a non-English locale.
3. Generate a different snippet text for the same event on repeated polls if the notification page content changes slightly (e.g. timestamps are rewritten), causing the same approval to be re-emitted.

Consider targeting connection-specific structured elements instead (e.g. notification items with a specific `data-` attribute or icon type), or at a minimum anchoring the match to the grammatical patterns LinkedIn actually uses (*"accepted your connection request"*, *"is now connected with you"*).

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 539-543

Comment:
**Class-name selector violates scraping rules**

`"button.artdeco-button[aria-label*='More']"` uses a LinkedIn design-system class name (`artdeco-button`), which directly violates the CLAUDE.md guideline: *"When DOM access is unavoidable, use minimal generic selectors — never class names tied to LinkedIn's layout."*

Since `aria-label*='More'` already constrains the match, the class prefix adds no resilience and is more brittle than it appears. Remove this selector from the fallback list; the three preceding `aria-label`-based and `:has-text` selectors already provide sufficient coverage without relying on a layout class.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: linkedin_mcp_server/notifications/poller.py
Line: 80-85

Comment:
**State is reloaded from disk on every poll cycle, discarding in-memory updates on failure**

`load_state()` is called inside the lock on every cycle. If `save_state(state)` fails silently (it catches all exceptions) after `state` was mutated, the next cycle reloads the pre-update state from disk and the same events are re-emitted to clients.

Consider loading the state once at poller startup and keeping it in memory across cycles, only reloading from disk if the in-memory state is unavailable. This pattern also eliminates repeated disk I/O.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat: add ability to listen for connecti..." | Re-trigger Greptile}

[greptile-apps]

Scraper lock not shared with SequentialToolExecutionMiddleware

The module docstring states: "Both SequentialToolExecutionMiddleware and the notification poller import this module so they contend on the same lock." This is incorrect. SequentialToolExecutionMiddleware creates its own private lock (self._lock = asyncio.Lock() in __init__); it never calls get_scraper_lock(). The poller acquires get_scraper_lock() while tool execution is serialised by a completely different lock instance, so concurrent browser access between a running tool and the poller is not actually prevented.

To fix this, SequentialToolExecutionMiddleware needs to be updated to use get_scraper_lock() instead of its own lock:

# sequential_tool_middleware.py
from linkedin_mcp_server.scraper_lock import get_scraper_lock

class SequentialToolExecutionMiddleware(Middleware):
    async def on_call_tool(self, context, call_next):
        async with get_scraper_lock():
            ...

Prompt To Fix With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/scraper_lock.py
Line: 1-19

Comment:
**Scraper lock not shared with `SequentialToolExecutionMiddleware`**

The module docstring states: *"Both `SequentialToolExecutionMiddleware` and the notification poller import this module so they contend on the same lock."* This is incorrect. `SequentialToolExecutionMiddleware` creates its own private lock (`self._lock = asyncio.Lock()` in `__init__`); it never calls `get_scraper_lock()`. The poller acquires `get_scraper_lock()` while tool execution is serialised by a completely different lock instance, so concurrent browser access between a running tool and the poller is not actually prevented.

To fix this, `SequentialToolExecutionMiddleware` needs to be updated to use `get_scraper_lock()` instead of its own lock:

```python
# sequential_tool_middleware.py
from linkedin_mcp_server.scraper_lock import get_scraper_lock

class SequentialToolExecutionMiddleware(Middleware):
    async def on_call_tool(self, context, call_next):
        async with get_scraper_lock():
            ...
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Clicking conversations marks them as read on LinkedIn

get_inbox_thread_ids extracts thread IDs by literally clicking each conversation item in the inbox, which triggers LinkedIn's read-receipt logic and marks messages as unread → read for the user. The background poller calls this on every cycle, silently marking up to 10 conversations as read every 5 minutes even when the user hasn't opened them.

Additionally, div[class*="listitem__link"] is a class-name-based selector, which violates the CLAUDE.md scraping rule: "never class names tied to LinkedIn's layout."

A better approach is to extract thread IDs from the href attributes of the <a> anchor elements rendered in the conversation list, without clicking:

const anchors = Array.from(document.querySelectorAll(
    'main a[href*="/messaging/thread/"]'
));
const results = [];
for (let i = 0; i < Math.min(anchors.length, limit); i++) {
    const match = anchors[i].href.match(/\/messaging\/thread\/([^/?#]+)/);
    if (match) results.push({ threadId: match[1] });
}
return results;

This approach is non-destructive and does not rely on class names.

Prompt To Fix With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 2186-2193

Comment:
**Clicking conversations marks them as read on LinkedIn**

`get_inbox_thread_ids` extracts thread IDs by literally clicking each conversation item in the inbox, which triggers LinkedIn's read-receipt logic and marks messages as unread → read for the user. The background poller calls this on every cycle, silently marking up to 10 conversations as read every 5 minutes even when the user hasn't opened them.

Additionally, `div[class*="listitem__link"]` is a class-name-based selector, which violates the CLAUDE.md scraping rule: *"never class names tied to LinkedIn's layout."*

A better approach is to extract thread IDs from the `href` attributes of the `<a>` anchor elements rendered in the conversation list, without clicking:

```js
const anchors = Array.from(document.querySelectorAll(
    'main a[href*="/messaging/thread/"]'
));
const results = [];
for (let i = 0; i < Math.min(anchors.length, limit); i++) {
    const match = anchors[i].href.match(/\/messaging\/thread\/([^/?#]+)/);
    if (match) results.push({ threadId: match[1] });
}
return results;
```

This approach is non-destructive and does not rely on class names.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Connection approval detection is English-only and prone to false positives

get_connection_approval_notifications identifies connection approvals by scanning notification text for the words "accepted" or "connected". This will:

1. Produce false positives for unrelated notifications containing these words (e.g. "You've been accepted into a group", "Your application was accepted").
2. Miss connection approvals entirely for users with LinkedIn set to a non-English locale.
3. Generate a different snippet text for the same event on repeated polls if the notification page content changes slightly (e.g. timestamps are rewritten), causing the same approval to be re-emitted.

Consider targeting connection-specific structured elements instead (e.g. notification items with a specific data- attribute or icon type), or at a minimum anchoring the match to the grammatical patterns LinkedIn actually uses ("accepted your connection request", "is now connected with you").

Prompt To Fix With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 2206-2229

Comment:
**Connection approval detection is English-only and prone to false positives**

`get_connection_approval_notifications` identifies connection approvals by scanning notification text for the words `"accepted"` or `"connected"`. This will:

1. Produce false positives for unrelated notifications containing these words (e.g. *"You've been accepted into a group"*, *"Your application was accepted"*).
2. Miss connection approvals entirely for users with LinkedIn set to a non-English locale.
3. Generate a different snippet text for the same event on repeated polls if the notification page content changes slightly (e.g. timestamps are rewritten), causing the same approval to be re-emitted.

Consider targeting connection-specific structured elements instead (e.g. notification items with a specific `data-` attribute or icon type), or at a minimum anchoring the match to the grammatical patterns LinkedIn actually uses (*"accepted your connection request"*, *"is now connected with you"*).

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Class-name selector violates scraping rules

"button.artdeco-button[aria-label*='More']" uses a LinkedIn design-system class name (artdeco-button), which directly violates the CLAUDE.md guideline: "When DOM access is unavoidable, use minimal generic selectors — never class names tied to LinkedIn's layout."

Since aria-label*='More' already constrains the match, the class prefix adds no resilience and is more brittle than it appears. Remove this selector from the fallback list; the three preceding aria-label-based and :has-text selectors already provide sufficient coverage without relying on a layout class.

Prompt To Fix With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/scraping/extractor.py
Line: 539-543

Comment:
**Class-name selector violates scraping rules**

`"button.artdeco-button[aria-label*='More']"` uses a LinkedIn design-system class name (`artdeco-button`), which directly violates the CLAUDE.md guideline: *"When DOM access is unavoidable, use minimal generic selectors — never class names tied to LinkedIn's layout."*

Since `aria-label*='More'` already constrains the match, the class prefix adds no resilience and is more brittle than it appears. Remove this selector from the fallback list; the three preceding `aria-label`-based and `:has-text` selectors already provide sufficient coverage without relying on a layout class.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

State is reloaded from disk on every poll cycle, discarding in-memory updates on failure

load_state() is called inside the lock on every cycle. If save_state(state) fails silently (it catches all exceptions) after state was mutated, the next cycle reloads the pre-update state from disk and the same events are re-emitted to clients.

Consider loading the state once at poller startup and keeping it in memory across cycles, only reloading from disk if the in-memory state is unavailable. This pattern also eliminates repeated disk I/O.

Prompt To Fix With AI

This is a comment left during a code review.
Path: linkedin_mcp_server/notifications/poller.py
Line: 80-85

Comment:
**State is reloaded from disk on every poll cycle, discarding in-memory updates on failure**

`load_state()` is called inside the lock on every cycle. If `save_state(state)` fails silently (it catches all exceptions) after `state` was mutated, the next cycle reloads the pre-update state from disk and the same events are re-emitted to clients.

Consider loading the state once at poller startup and keeping it in memory across cycles, only reloading from disk if the in-memory state is unavailable. This pattern also eliminates repeated disk I/O.

How can I resolve this? If you propose a fix, please make it concise.

[stickerdaniel]

@aspectrr thanks for your PRs! I would polish the recently added messaging tools first before adding new features. (307 / 304)