debug-hmr backlog sync + fix(debug): logpoint async eval (eval_expression + create_task defer + scalar decode)

[Alex1980Alex]

Scope note: origin/master was stale (at 1872dff); this branch is 29 commits ahead — the entire unpushed debug-hmr development (roadmap 260511: P0.A–G, logpoints, capture-mode, arm-warm/next-rphost, error-envelopes, snapshot/replay, coverage export…). The logpoint fix below is the head commit and cannot be isolated — it edits logpoints.py, which does not exist on origin/master (introduced by the P0.B commit). So this PR effectively syncs the debug-hmr backlog + the logpoint fix.

---

Problem (head commit 6503fc9)

Logpoints (debug_set_logpoint) never captured variable values:

1. fire_logpoint called a non-existent client.evaluate() → AttributeError (the real method is eval_expression).
2. Even after fixing the name, eval_expression awaits the async exprEvaluated event delivered by ping_loop._handle_command — which cannot run while we are inside it (re-entrancy deadlock) → eval timed out → [].

Fix

• Defer eval + log + Continue to a separate task (asyncio.create_task) so the ping loop is free to deliver exprEvaluated. Always Continue in finally so a stuck logpoint never freezes the target.
• Add _scalar(): decode RDBG resultValueInfo (valueString / valueBoolean→Истина/Ложь / valueDecimal / pres base64) into clean scalars.

Tests

• New tests/test_logpoints.py (9 tests). Full suite: 262 passed, no regression.

Verified live

VA-driven write to РС гкс_УдостоверенияКачестваПоРегистрацииПЛК halts at RecordSetModule:41; logpoint captured ДокументРегистрации / Отказ=Ложь / Замещение=Ложь / Количество=1 correctly.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces several debugging features to the 1C debug MCP server, including hit-conditions, logpoints, silent auto-attaching of warm-pool rphosts, code coverage tracking, exception breakpoint filtering, and snapshot recording for post-mortem replay. Feedback on these changes identifies three critical issues: first, background tasks created via asyncio.create_task in logpoints.py must maintain strong references to prevent premature garbage collection; second, the _reapply_bp_workspace method in mcp_debug_server.py should preserve breakpoint conditions by utilizing the _build_bp_info_xml helper; and third, _aggregate_breakpoints should support both a conditions dictionary and a fallback condition field.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

In Python's asyncio, creating a background task using asyncio.create_task without keeping a strong reference to the returned task object can lead to the task being garbage collected mid-execution. This is because the event loop only maintains weak references to tasks. If the task is garbage collected before it completes, the logpoint evaluation will fail silently, and the finally block might not execute, leaving the target frozen.

To prevent this, store a reference to the task in a set on the client object, and remove it when the task completes.

Suggested change

	asyncio.create_task(
	_eval_log_continue(client, target_id, key, template, log_dir))
	task = asyncio.create_task(
	_eval_log_continue(client, target_id, key, template, log_dir))
	if not hasattr(client, "_background_tasks"):
	client._background_tasks = set()
	client._background_tasks.add(task)
	task.add_done_callback(client._background_tasks.discard)

[Alex1980Alex]

✅ Fixed in dd7ce92: held a strong reference to the deferred task in a module-level _active_tasks set + task.add_done_callback(_active_tasks.discard) (equivalent to the suggested client._background_tasks). Merged.

[gemini-code-assist]

The _reapply_bp_workspace method currently reapplies breakpoints using a hardcoded XML structure that completely omits the condition field. As a result, any conditional breakpoints (or logpoints/hit conditions) reapplied during target startup or HMR recovery will lose their conditions and silently revert to unconditional breakpoints.

We should use the existing _build_bp_info_xml helper to correctly preserve the conditions stored in the cache.

            bp_xml = "".join(
                _build_bp_info_xml(L, entry.get("conditions", {}).get(str(L), entry.get("condition", "")))
                for L in entry["lines"]
            )

[Alex1980Alex]

✅ Fixed in 3957042: _reapply_bp_workspace now routes through the shared _build_bp_info_xml(L, entry.get('condition','')) helper, so cached conditions survive targetStarted/HMR re-apply. +2 regression tests (tests/test_reapply_condition.py). Merged.

[gemini-code-assist]

To support the new "conditions" dictionary in the cache, _aggregate_breakpoints should look up the condition for each line from the "conditions" dictionary first, falling back to the single "condition" field.

Suggested change

	cond = entry.get("condition", "") or ""
	for line in entry.get("lines", []):
	try:
	line_set.add(int(line))
	line_map[int(line)] = cond
	for line in entry.get("lines", []):
	try:
	cond = entry.get("conditions", {}).get(str(line)) or entry.get("condition", "") or ""
	line_map[int(line)] = cond

[Alex1980Alex]

Not applicable: the breakpoint cache stores a single condition per entry (one per set_breakpoints call) — there is no per-line conditions dict. _aggregate_breakpoints already assigns entry['condition'] to each of the entry's lines (lines 190-193), so conditions are preserved. The defensive conditions-dict lookup would be a no-op against the current model. Resolving as already-correct.