Skip to content

feat: verify pushed config and warn on fields the API did not persist#96

Open
aicayzer wants to merge 1 commit into
elevenlabs:mainfrom
aicayzer:feat/push-verification
Open

feat: verify pushed config and warn on fields the API did not persist#96
aicayzer wants to merge 1 commit into
elevenlabs:mainfrom
aicayzer:feat/push-verification

Conversation

@aicayzer

Copy link
Copy Markdown

Problem

Push reports success purely from the HTTP response. The SDK serializes requests with unrecognizedObjectKeys: "strip", so any field the bundled SDK doesn't model (or that reaches it miscased) is silently deleted before the request goes out, and the CLI still prints success. That's the common mechanism behind #90, #93 and #94, and it will recur whenever the platform adds a field before the SDK pin catches up (#82 is the flip side of the same problem).

Fix

After a successful push, compare what was pushed against what the API reports as persisted, and warn with the exact dropped paths:

  • agents push reads each agent back after create/update (including branch pushes) and runs a presence-only subset check (every locally specified key must exist live)
  • tools push checks against the tool config already returned by the create/update response, so no extra API call
  • warnings are non-fatal, and a failed verification read never fails the push

Example output:

  ⚠ My Agent: 1 field(s) in the local config were not persisted by the API:
      - conversation_config.agent.dynamic_variables.dynamic_variable_placeholders
    These fields may not be supported by the CLI's bundled SDK. Run 'elevenlabs agents pull' to inspect the live config.

Design notes:

  • presence-only (keys, not values) to avoid false positives from server-side defaults and normalization; arrays are treated as leaves
  • the trade-off: it can't see drops where the server always echoes the key with defaults (e.g. the response-only platform_settings.safety block) or changes inside arrays; it catches missing keys, which is the dominant failure mode here
  • the deprecated tools-vs-tool_ids cleanup is mirrored on the expected side, so it isn't reported as a drop
  • non-goal: detecting local deletions (PATCH merges, so removing a key locally never removes it live; existing behaviour)

Tests

16 new tests in verify.test.ts: unit coverage of the path diff plus the agent/tool verification flows with mock clients (warning fires on a stripped response, silence on a clean push, read failure warns without failing the push). Full suite 218/218, lint and build clean.

- new findMissingPaths: presence-only subset check between the pushed
  config and what the API reports as persisted
- agents push reads each agent back after create/update (including
  branch pushes) and warns with the dropped field paths
- tools push verifies against the tool config already returned by the
  create/update response, so no extra API call is made
- warnings are non-fatal and a failed verification read never fails
  the push

The SDK serializes requests with unrecognizedObjectKeys: "strip", so
any field the bundled SDK does not model is silently dropped before it
reaches the API while the CLI reports success. This surfaces the
dropped fields instead of printing an unconditional success.
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