Skip to content

feat: add live task progress updates across chat frontends#556

Merged
buger merged 4 commits intomainfrom
feat/live-task-progress-updates
Mar 21, 2026
Merged

feat: add live task progress updates across chat frontends#556
buger merged 4 commits intomainfrom
feat/live-task-progress-updates

Conversation

@buger
Copy link
Copy Markdown
Contributor

@buger buger commented Mar 21, 2026

Summary

  • add configurable live task progress updates with shared trace resolution and smarter progress rendering
  • reuse a single live-update message across Slack, Telegram, and Teams, with frontend-specific sinks and fallback cleanup
  • improve task trace rendering and add end-to-end mocked coverage for Slack, Telegram, and Teams live updates

Testing

  • npx jest tests/integration/slack-live-task-updates.test.ts tests/integration/telegram-live-task-updates.test.ts tests/integration/teams-live-task-updates.test.ts --runInBand
  • npm run build:cli
  • pre-commit suite

@probelabs
Copy link
Copy Markdown
Contributor

probelabs Bot commented Mar 21, 2026

PR Overview: Live Task Progress Updates Across Chat Frontends

Summary

This PR introduces a live task progress update system that provides real-time status updates to users during long-running AI tasks across Slack, Telegram, and Teams frontends. The system posts a "working on it" placeholder message and periodically updates it with AI-generated progress summaries based on execution traces, then replaces it with the final answer when complete.

Files Changed Analysis

New Core Files (4)

  • src/agent-protocol/task-live-updates.ts (+772 lines): Core manager class with progress summarization, trace serialization integration, stall detection, and metadata refresh logic
  • src/agent-protocol/task-live-update-slack.ts (+92 lines): Slack-specific sink implementation with message update/delete fallback
  • src/agent-protocol/task-live-update-teams.ts (+88 lines): Teams-specific sink with activity update/delete
  • src/agent-protocol/task-live-update-telegram.ts (+99 lines): Telegram-specific sink with editMessageText/deleteMessage

New Infrastructure (1)

  • src/agent-protocol/task-trace-resolution.ts (+32 lines): Shared trace reference resolution utility

Modified Core Files (4)

  • src/agent-protocol/track-execution.ts (+200/-100): Integrates live update manager into task lifecycle with new liveUpdates option
  • src/agent-protocol/trace-serializer.ts (+37/-4): Improvements to trace rendering (lifecycle span handling, skills display, array formatting)
  • src/agent-protocol/task-progress-tool.ts (+7/-11): Uses new trace resolution utility
  • src/types/config.ts (+41 lines): Adds TaskLiveUpdatesConfig interface

Frontend Integration (7 files)

  • src/slack/socket-runner.ts (+44 lines): Creates SlackTaskLiveUpdateSink for socket mode
  • src/teams/webhook-runner.ts (+16 lines): Creates TeamsTaskLiveUpdateSink
  • src/telegram/polling-runner.ts (+17 lines): Creates TelegramTaskLiveUpdateSink
  • src/slack/client.ts (+25 lines): Adds chat.delete method
  • src/teams/client.ts (+54 lines): Adds updateMessage and deleteMessage methods
  • src/telegram/client.ts (+45 lines): Adds editMessageText and deleteMessage methods
  • src/frontends/{slack,teams,telegram}-frontend.ts (+36 lines total): Suppress duplicate replies when live updates active

Configuration & Tests (8 files)

  • src/generated/config-schema.ts (+117/-6): JSON schema for task_live_updates config
  • src/config.ts (+1 line): Adds task_live_updates to allowed workflow keys
  • src/logger.ts (+25/-3): Adds AsyncLocalStorage-based task context tracking
  • tests/integration/{slack,teams}-live-task-updates.test.ts (+508 lines): End-to-end integration tests
  • tests/frontends/{slack,teams,telegram}-frontend.test.ts (+202 lines): Verify duplicate-reply suppression

Build Infrastructure (3 files)

  • scripts/build-oss.sh (+50/-20): Improves OSS build isolation using temporary workspace
  • package.json (+2/-1): Adds build:oss script target
  • .gitignore (+1 line): Adds .enterprise-stash/ to ignored paths

Total: 30 files changed, +2514/-154 lines

Architecture & Impact Assessment

What This PR Accomplishes

  1. Unified Live Update Architecture: A sink-based abstraction (TaskLiveUpdateSink) that works across Slack, Telegram, and Teams with frontend-specific implementations
  2. AI-Powered Progress Summarization: Uses a fast LLM (gemini-3.1-flash-lite-preview) to generate concise 4-bullet progress updates from execution traces
  3. Smart Trace Resolution: Shared resolveTaskTraceReference() utility that handles both trace IDs and trace files with fallback logic
  4. Stall Detection & Fallback: When semantic progress stalls, publishes deterministic fallback updates based on trace patterns
  5. Metadata Refresh: Updates timing metadata every 5 seconds without additional LLM calls
  6. Graceful Degradation: If message updates fail, falls back to posting new messages and cleans up stale ones

Key Technical Changes

1. TaskLiveUpdateManager Core Flow

trackExecution() starts task
    ↓
TaskLiveUpdateManager.start() → sink.start()
    ↓
10s delay → first tick
    ↓
Periodic ticks (configurable interval, default 10s)
    ├─ Fetch trace spans (serializeTraceForPrompt)
    ├─ Summarize with LLM (summarizeTaskProgress)
    ├─ Decorate with metadata (elapsed, skills, trace_id)
    └─ sink.update()
    ↓
Task completes → sink.complete() or sink.fail()

2. Sink Pattern

interface TaskLiveUpdateSink {
  readonly kind: string;
  start(): Promise<{ref?} | null>;
  update(text: string): Promise<{ref?} | null>;
  complete(text: string): Promise<{ref?} | null>;
  fail(text: string): Promise<{ref?} | null>;
}

Each platform implements this interface:

  • Slack: chat.postMessagechat.updatechat.delete (fallback cleanup)
  • Teams: sendMessageupdateMessagedeleteMessage
  • Telegram: sendMessageeditMessageTextdeleteMessage

3. Configuration Schema

task_live_updates:
  enabled: true
  interval_seconds: 10  # update frequency
  model: gemini-3.1-flash-lite-preview
  provider: google
  prompt: "..."  # custom system prompt
  initial_message: ""  # placeholder text
  max_trace_chars: 12000
  frontends:
    slack: { enabled: true }
    telegram: { enabled: true }
    teams: { enabled: true }

Affected System Components

  1. Agent Protocol Layer:

    • trackExecution(): Now accepts liveUpdates option with sink and config
    • trace-serializer: Enhanced to render skills/activated_skills and handle lifecycle spans better
    • task-trace-resolution: New utility for consistent trace ID/file resolution
  2. Frontend Runners:

    • All three chat runners now create platform-specific sinks and pass them to trackExecution()
    • Frontend event handlers suppress duplicate direct replies when live updates are active
  3. Client Libraries:

    • Slack: Added chat.delete method
    • Teams: Added updateMessage and deleteMessage methods
    • Telegram: Added editMessageText and deleteMessage methods
  4. Task Store Integration:

    • Live update references (message timestamps, activity IDs) stored in task metadata
    • Progress history appended to task history with kind: task_live_update
  5. Logger Enhancement:

    • Added AsyncLocalStorage-based task context tracking
    • All logs now include task_id when in task context

Component Relationships

graph TB
    subgraph "Task Execution"
        TE[trackExecution] --> TLM[TaskLiveUpdateManager]
        TE --> Engine[StateMachineExecutionEngine]
    end
    
    subgraph "Progress Pipeline"
        TLM --> TS[serializeTraceForPrompt]
        TS --> SA[summarizeTaskProgress]
        SA --> Probe[ProbeAgent LLM]
    end
    
    subgraph "Platform Sinks"
        TLM --> SlackSink[SlackTaskLiveUpdateSink]
        TLM --> TeamsSink[TeamsTaskLiveUpdateSink]
        TLM --> TelegramSink[TelegramTaskLiveUpdateSink]
    end
    
    subgraph "Client APIs"
        SlackSink --> SlackClient[SlackClient chat.update/delete]
        TeamsSink --> TeamsClient[TeamsClient updateMessage/deleteMessage]
        TelegramSink --> TelegramClient[TelegramClient editMessageText/deleteMessage]
    end
    
    subgraph "Trace Backends"
        TS --> Grafana[Grafana Tempo]
        TS --> Jaeger[Jaeger]
        TS --> Local[Local NDJSON Files]
    end
Loading

Scope Discovery & Context Expansion

Direct Impact

  • All interactive chat frontends (Slack, Telegram, Teams) now support live progress updates
  • Task tracking system gains a new dimension of real-time user feedback
  • Trace serialization is enhanced with better rendering of skills and lifecycle spans
  • Logger now supports task context propagation via AsyncLocalStorage

Related Systems (Not Modified But Relevant)

  • Task Queue (src/agent-protocol/task-queue.ts): Could benefit from live updates for async workers
  • Task Evaluator (src/agent-protocol/task-evaluator.ts): Complementary post-completion evaluation
  • A2A Frontend (src/agent-protocol/a2a-frontend.ts): Agent-to-agent protocol could expose progress updates
  • TUI Frontend (src/tui/tui-frontend.ts): Terminal UI could show similar progress indicators
  • WhatsApp Frontend (src/frontends/whatsapp-frontend.ts): Could be added with message edit support

Configuration Impact

  • New top-level config: task_live_updates (boolean or object)
  • Per-frontend overrides: task_live_updates.frontends.{slack,telegram,teams}.enabled
  • Telemetry integration: Respects slack.telemetry / telemetry.enabled for trace_id inclusion

Testing Coverage

  • Integration tests: Full end-to-end flows for Slack and Teams with mocked clients
  • Frontend tests: Verify duplicate-reply suppression when live updates active
  • Note: Telegram integration test file is mentioned in PR but not visible in diff

Potential Follow-up Work

  1. Telegram integration test: Add tests/integration/telegram-live-task-updates.test.ts
  2. WhatsApp support: Add WhatsAppTaskLiveUpdateSink (WhatsApp API supports message editing)
  3. TUI progress bars: Expose progress updates to terminal UI
  4. A2A progress streaming: Expose live updates via agent-to-agent protocol
  5. Custom prompts: Allow users to customize progress update format
  6. Progress callbacks: Webhook or event-based progress notifications for external integrations

References

Core Implementation

  • src/agent-protocol/task-live-updates.ts:1-772 - TaskLiveUpdateManager, config resolution, summarization
  • src/agent-protocol/task-live-update-slack.ts:1-92 - Slack sink implementation
  • src/agent-protocol/task-live-update-teams.ts:1-88 - Teams sink implementation
  • src/agent-protocol/task-live-update-telegram.ts:1-99 - Telegram sink implementation
  • src/agent-protocol/task-trace-resolution.ts:1-32 - Trace reference resolution utility

Integration Points

  • src/agent-protocol/track-execution.ts:68-316 - Live update manager integration
  • src/slack/socket-runner.ts:964-1002,1214-1255 - Slack sink creation
  • src/teams/webhook-runner.ts:274-305 - Teams sink creation
  • src/telegram/polling-runner.ts:252-283 - Telegram sink creation

Client Enhancements

  • src/slack/client.ts:135-159 - chat.delete method
  • src/teams/client.ts:92-146 - updateMessage/deleteMessage methods
  • src/telegram/client.ts:110-151 - editMessageText/deleteMessage methods

Frontend Behavior

  • src/frontends/slack-frontend.ts:288-318 - Suppress duplicate replies
  • src/frontends/teams-frontend.ts:149-150 - Suppress duplicate replies
  • src/frontends/telegram-frontend.ts:229-230 - Suppress duplicate replies

Configuration

  • src/types/config.ts:1673-1733 - TaskLiveUpdatesConfig interface
  • src/generated/config-schema.ts:231-238 - JSON schema for task_live_updates
  • src/config.ts:1897 - Adds task_live_updates to allowed workflow keys

Tests

  • tests/integration/slack-live-task-updates.test.ts:1-259 - Slack E2E tests
  • tests/integration/teams-live-task-updates.test.ts:1-249 - Teams E2E tests
  • tests/frontends/slack-frontend.test.ts:55-163 - Task context and duplicate-reply tests
  • tests/frontends/teams-frontend.test.ts:115-163 - Duplicate-reply suppression test
  • tests/frontends/telegram-frontend.test.ts:87-127 - Duplicate-reply suppression test

Infrastructure

  • src/logger.ts:40-197 - AsyncLocalStorage task context tracking
  • scripts/build-oss.sh:1-61 - Improved OSS build isolation
Metadata
  • Review Effort: 4 / 5
  • Primary Label: feature

Powered by Visor from Probelabs

Last updated: 2026-03-21T17:04:42.077Z | Triggered by: pr_updated | Commit: 6802d49

💡 TIP: You can chat with Visor using /visor ask <your question>

@probelabs
Copy link
Copy Markdown
Contributor

probelabs Bot commented Mar 21, 2026

✅ Security Check Passed

No security issues found – changes LGTM.

Architecture Issues (10)

Severity Location Issue
🟠 Error src/agent-protocol/task-live-updates.ts:772
The TaskLiveUpdateManager class is 772 lines with multiple responsibilities: progress summarization, trace serialization, stall detection, metadata refresh, and LLM integration. This violates Single Responsibility Principle and makes the class hard to test and maintain.
💡 SuggestionExtract separate classes: ProgressSummarizer (LLM calls), TraceMonitor (trace fetching/caching), StallDetector (stall logic), and MetadataDecorator (formatting). Keep TaskLiveUpdateManager as a coordinator only.
🟠 Error src/agent-protocol/task-live-updates.ts:595
Direct require() of @probelabs/probe inside summarizeTaskProgress creates tight coupling to a specific LLM library. This makes testing difficult and prevents swapping LLM providers.
💡 SuggestionInject the LLM summarizer as a dependency via TaskLiveUpdateDeps.summarizeProgress. The default implementation can use ProbeAgent, but this allows mocking and provider swapping.
🟠 Error src/agent-protocol/task-live-update-slack.ts:1
SlackTaskLiveUpdateSink, TeamsTaskLiveUpdateSink, and TelegramTaskLiveUpdateSink share nearly identical logic: try update, fallback to post, cleanup stale messages on final. Only the API calls differ.
💡 SuggestionExtract a generic BaseTaskLiveUpdateSink class with template methods. Platform sinks only implement platform-specific API calls (updateMessage, postMessage, deleteMessage). Reduces 279 lines to ~100.
🟢 Info src/agent-protocol/task-trace-resolution.ts:1
The resolveTaskTraceReference function is a trivial 32-line utility that could be inlined. It doesn't provide enough value to justify a separate module.
💡 SuggestionMerge this into trace-serializer.ts or track-execution.ts. Only extract if it grows more complex or is used by 5+ modules.
🟡 Warning src/agent-protocol/task-live-updates.ts:449
buildStallFallbackSummary contains hardcoded pattern matching for specific trace patterns (search.delegate, extract, engineer-task, etc.). This creates a fragile special-case system that breaks as trace formats evolve.
💡 SuggestionReplace hardcoded pattern matching with a configurable rule-based system or a simpler generic fallback that doesn't claim specific knowledge. Consider making this pluggable.
🟡 Warning src/agent-protocol/track-execution.ts:117
The trackExecution function now has 7 different concerns: task lifecycle, heartbeat, trace capture, live updates, response extraction, evaluation, and error handling. Adding live updates pushed it from complex to unmanageable.
💡 SuggestionExtract a TaskExecutionOrchestrator class that coordinates these concerns. Each concern (heartbeat, live updates, evaluation) should be a separate composable component.
🟡 Warning src/agent-protocol/task-live-updates.ts:335
Multiple hardcoded timing constants scattered throughout: DEFAULT_TASK_LIVE_UPDATE_FIRST_UPDATE_DELAY_SECONDS (10), DEFAULT_TASK_LIVE_UPDATE_INTERVAL_SECONDS (10), DEFAULT_TASK_LIVE_UPDATE_METADATA_REFRESH_SECONDS (5), DEFAULT_TASK_LIVE_UPDATE_STALL_FALLBACK_SECONDS (60). These are not configurable per-task.
💡 SuggestionCreate a TaskLiveUpdateTiming config object that can be overridden per-task. Different tasks may need different update frequencies (fast vs slow operations).
🟡 Warning src/agent-protocol/task-live-updates.ts:680
The normalizeProgressSummary function has hardcoded knowledge of specific bullet labels (Progress, Last done, Now, Waiting on). This creates a fragile contract with the LLM prompt.
💡 SuggestionDefine a structured schema for progress updates and enforce it via JSON schema validation in the LLM call. The current regex parsing is brittle.
🟡 Warning src/frontends/slack-frontend.ts:288
The isLiveTaskUpdatesMode method checks for inbound Slack payload and config, but doesn't verify that a sink was actually created. This creates a gap where live updates might be configured but not active, yet normal replies are suppressed.
💡 SuggestionPass the actual sink state to the frontend, or check task metadata for live update refs. Don't rely solely on config presence.
🟡 Warning src/logger.ts:40
Adding AsyncLocalStorage for task context to Logger is a concern violation. Logger should only handle logging, not async context tracking. This creates hidden dependencies.
💡 SuggestionCreate a separate TaskContextManager for async context tracking. Logger can use it via dependency injection, but shouldn't own the storage.

Quality Issues (26)

Severity Location Issue
🔴 Critical src/agent-protocol/task-live-updates.ts:732
summarizeTaskProgress() uses dynamic require() for @probelabs/probe without error handling. If the module is missing or fails to load, the error will be unhandled and crash the task.
💡 SuggestionWrap the require in a try-catch and provide a fallback or clear error message: try { const { ProbeAgent } = require('@probelabs/probe'); } catch (err) { logger.error('ProbeAgent not available'); return 'Progress update unavailable'; }
🟠 Error src/agent-protocol/task-live-updates.ts:665
The tick() method is overly complex with multiple responsibilities: trace fetching, serialization, summarization, stall detection, metadata refresh, and message publishing. This violates Single Responsibility Principle and makes the method hard to test and maintain.
💡 SuggestionExtract smaller methods: shouldSkipTick(), shouldPublishStallFallback(), generateProgressUpdate(), publishUpdate(). Each method should have a single clear purpose.
🟠 Error src/agent-protocol/task-live-updates.ts:595
The complete() method swallows errors during final update publication. Users won't receive their final answer if the sink fails, but the task is marked as completed anyway.
💡 SuggestionEither propagate the error to fail the task, or at least store the failure in task metadata so it can be surfaced later. Consider a retry mechanism for critical final updates.
🟠 Error src/agent-protocol/task-live-updates.ts:607
The fail() method also swallows errors. If the failure notification itself fails, there's no way for users to know their task failed.
💡 SuggestionImplement a fallback notification mechanism (e.g., store in task history) or propagate the error to ensure failure is communicated.
🟢 Info src/agent-protocol/task-live-updates.ts:565
The start() method has complex timer setup logic with unref() calls but no comments explaining why unref() is needed or what it does.
💡 SuggestionAdd a comment: // unref() allows the process to exit even if timers are still active, preventing hanging in CLI mode
🟢 Info src/agent-protocol/trace-serializer.ts:1000
After adding recursive child rendering when shouldSkipLifecycleSpan returns true, the function returns without rendering the current node. This is correct but the comment explaining why would help maintainers.
💡 SuggestionAdd a comment: // Skip rendering lifecycle wrapper spans but still render their children - this filters out noise while preserving the actual work spans
🟢 Info src/agent-protocol/task-live-updates.ts:314
DEFAULT_TASK_LIVE_UPDATE_STALL_FALLBACK_SECONDS is set to 60 without documentation explaining why this specific threshold was chosen or how it relates to user expectations.
💡 SuggestionAdd a comment explaining the rationale: // 60s is chosen because most AI steps complete within 30-45s; longer gaps indicate genuine stalls worth notifying about
🟢 Info src/agent-protocol/task-live-updates.ts:309
DEFAULT_TASK_LIVE_UPDATE_METADATA_REFRESH_SECONDS is 5 without explanation of why metadata needs more frequent updates than progress summaries.
💡 SuggestionAdd comment: // Refresh timing metadata every 5s so elapsed time updates feel responsive, even when semantic progress hasn't changed
🟡 Warning tests/integration/slack-live-task-updates.test.ts:14
Test uses magic number '2000.1' for message timestamp without semantic meaning. This timestamp appears to be arbitrarily chosen to make assertions pass rather than representing a meaningful value derived from the system behavior.
💡 SuggestionUse a named constant or derive the expected timestamp from the mock setup. For example: const EXPECTED_MESSAGE_TS = '2000.1'; at the top of the test to make it clear this is the mock response value.
🟡 Warning tests/integration/slack-live-task-updates.test.ts:14
Test uses magic number '1800.1' for event timestamp without clear semantic meaning. The relationship between this timestamp and the expected '2000.1' response timestamp is not documented.
💡 SuggestionUse named constants with clear names: const EVENT_TS = '1800.1'; const RESPONSE_TS = '2000.1'; Add a comment explaining why these differ if it's intentional.
🟡 Warning tests/integration/teams-live-task-updates.test.ts:231
Test uses magic string 'act.reply1' for activity ID without semantic meaning. This appears to be a hardcoded value chosen to match the mock response rather than a derived expected value.
💡 SuggestionUse a named constant: const EXPECTED_ACTIVITY_ID = 'act.reply1'; and document that this matches the mock client's response.
🟡 Warning src/agent-protocol/task-live-updates.ts:565
The start() method catches and logs errors but continues execution, which could lead to silent failures. If sink initialization fails, the live update system won't work but the task continues as if everything is fine.
💡 SuggestionConsider propagating the error or setting a flag to disable future updates. At minimum, track the failure state so subsequent operations can check if the sink is functional.
🟡 Warning src/agent-protocol/task-live-update-slack.ts:52
The publish() method has a fallback from chat.update to chat.postMessage, but if both fail, it returns null without any indication of failure. The caller cannot distinguish between 'nothing to update' and 'update failed'.
💡 SuggestionReturn an error indicator or throw an exception when both update and post fail. The current silent failure makes debugging difficult.
🟡 Warning src/agent-protocol/task-live-update-teams.ts:50
Similar to Slack sink, the Teams publish() method fails silently when both updateMessage and sendMessage fail. No error propagation or status indication.
💡 SuggestionReturn an error object or throw when all attempts fail. Consider adding a max retry counter before giving up.
🟡 Warning src/agent-protocol/task-live-update-telegram.ts:54
Telegram sink has the same silent failure pattern. When editMessageText and sendMessage both fail, the method returns null with no error information.
💡 SuggestionImplement consistent error reporting across all sinks. Return { ok: false, error: string } or similar to indicate failure reasons.
🟡 Warning src/agent-protocol/track-execution.ts:197
Empty catch block when updating task metadata with trace_id. If this update fails, the trace_id is lost and cannot be recovered, but the error is silently ignored.
💡 SuggestionAt minimum log a warning: logger.warn(`Failed to store trace_id for task ${task.id}: ${err}`); Consider retrying or storing in a fallback location.
🟡 Warning src/agent-protocol/track-execution.ts:231
Empty catch block when recording sink references. If live update metadata cannot be stored, the frontend cannot track the update message, but this is silently ignored.
💡 SuggestionLog a warning so failures are visible: logger.warn(`Failed to store live update ref for task ${task.id}: ${err}`);
🟡 Warning src/agent-protocol/track-execution.ts:241
Empty catch block when appending live update history. Progress history is lost if storage fails, with no indication of the problem.
💡 SuggestionAdd logging: logger.warn(`Failed to append live update to history for task ${task.id}: ${err}`);
🟡 Warning src/logger.ts:115
The withTaskContext() method doesn't validate the taskId parameter. Passing null, undefined, or empty string could cause issues with context tracking.
💡 SuggestionAdd validation: if (!taskId || typeof taskId !== 'string') throw new Error('taskId must be a non-empty string');
🟡 Warning src/agent-protocol/task-live-updates.ts:432
The tick() method checks `this.completed` at the start but not after async operations. If the task completes during trace serialization or summarization, the method may still publish an update after completion.
💡 SuggestionThe code already has completion checks after async operations (lines 599, 611), which is good. However, consider adding a check before the final sink.update() call as well.
🟡 Warning src/agent-protocol/task-live-updates.ts:565
The start() method checks `if (this.started) return;` but doesn't check if already completed. If start() is called after complete(), it could still set up timers.
💡 SuggestionAdd: if (this.started || this.completed) return; to prevent starting timers on a completed task.
🟡 Warning tests/integration/slack-live-task-updates.test.ts:175
Test only covers the happy path where live updates work correctly. Missing test cases for: sink initialization failure, chat.update failure with fallback, chat.postMessage failure, trace serialization failure, LLM summarization failure.
💡 SuggestionAdd negative test cases: test('handles sink initialization failure gracefully'), test('falls back to postMessage when update fails'), test('handles trace serialization errors'), test('handles LLM summarization errors')
🟡 Warning tests/integration/teams-live-task-updates.test.ts:157
Teams integration test lacks negative scenarios. No tests for: updateMessage failure, sendMessage failure, network errors, timeout scenarios.
💡 SuggestionAdd test cases that mock client failures to verify error handling and fallback behavior.
🟡 Warning src/agent-protocol/task-live-updates.ts:732
Using dynamic require() for @probelabs/probe is a security and maintainability concern. The dependency should be statically imported at the top of the file.
💡 SuggestionChange to static import: import { ProbeAgent } from '@probelabs/probe'; If dynamic loading is needed for OSS builds, use a conditional import with better error handling.
🟡 Warning src/agent-protocol/task-live-updates.ts:732
Direct dependency on @probelabs/probe creates tight coupling. The summarizeProgress function should accept an external summarizer dependency instead of hardcoding the ProbeAgent.
💡 SuggestionThe TaskLiveUpdateDeps interface already has summarizeProgress as an optional dependency. Use dependency injection consistently instead of falling back to a hardcoded implementation.
🟡 Warning src/agent-protocol/task-live-updates.ts:432
The tick() method serializes the trace on every call even if the trace hasn't changed. The traceSnapshot comparison happens after serialization, wasting resources.
💡 SuggestionCheck if trace reference has changed before serializing. Add a quick check: if (traceRef === this.lastSerializedTraceRef) return; before calling serializeTrace().

Powered by Visor from Probelabs

Last updated: 2026-03-21T16:59:26.471Z | Triggered by: pr_updated | Commit: 6802d49

💡 TIP: You can chat with Visor using /visor ask <your question>

@buger buger merged commit c70b95b into main Mar 21, 2026
13 of 16 checks passed
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.

1 participant