Skip to content

fix: report DSH runtime events to AgentGuard Cloud - #121

Merged
Mr-Lucky merged 2 commits into
mainfrom
fix/dsh-cloud-event-reporting
Aug 25, 2026
Merged

fix: report DSH runtime events to AgentGuard Cloud#121
Mr-Lucky merged 2 commits into
mainfrom
fix/dsh-cloud-event-reporting

Conversation

@Mr-Lucky

Copy link
Copy Markdown
Contributor

Summary

Report DSH runtime audit events to AgentGuard Cloud when connected. Failed uploads are persisted to the local event spool and retried on subsequent tool calls, with serialized spool access to prevent duplicate reporting during concurrent executions.

Also clean stale build output before TypeScript compilation and isolate DSH auto-detection in CLI initialization tests.

Type

  • Bug fix
  • New feature / detection rule
  • Refactoring
  • Documentation

Testing

  • npm run build passes
  • npm test passes (32 tests)
  • Manually tested the change

Related Issues

Closes #

@Mr-Lucky
Mr-Lucky merged commit 51d5ea6 into main Aug 25, 2026
4 checks passed
@github-actions

Copy link
Copy Markdown

AgentGuard PR Review

This patch introduces a couple of concrete regressions in DSH cloud reporting and test setup.

  1. severity: high — src/dsh/runtime.ts (evaluateAndAuditDshAction, new client.ingestEvents([event]) call and spool flush)
    What can go wrong: Each DSH action now performs synchronous cloud ingestion before returning, and the fallback path can spool the current event plus previously queued events. Because failures are swallowed, repeated ingestion errors can cause the same event to be retried many times across runs, and a partial flush failure can leave the spool in an inconsistent state where some events are lost or duplicated. The code also reports the current event only after audit write, but the earlier flush-before-evaluate step can turn a harmless event-evaluation path into one that depends on network/storage availability.
    Fix: Make ingestion strictly append-only and idempotent: persist the event locally first, then enqueue async upload with explicit acknowledgements/removal only after successful server response. Keep flushing separated from per-request evaluation, and preserve failed flush state atomically if any upload fails.

  2. severity: medium — src/dsh/runtime.ts (withDshSpoolLock using an in-memory Map<string, Promise<void>>)
    What can go wrong: The lock only serializes within a single Node process. If multiple processes or workers share the same eventSpoolPath, concurrent flush/spool operations can still race, corrupt the JSONL spool, or lose events. This is especially risky because the file path is configurable and used for security audit data.
    Fix: Use an actual file lock or atomic rename/write strategy around spool operations, or otherwise guarantee a single writer per spool path across processes.

  3. severity: medium — src/tests/cli-init.test.ts (environment overrides in both init tests)
    What can go wrong: The tests now force DSH_HOME to a missing directory and DSH_SHELL=0. If CLI init logic relies on those variables being absent or set differently, these tests may no longer exercise the real auto-detection path and can mask regressions in DSH setup behavior.
    Fix: Scope the overrides to only the specific behavior under test, and add separate coverage for the default environment-detection path to ensure init --agent auto still works when DSH is installed.

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.

2 participants