…ons detail (#565)

The except ResourceConnectionError block in _apply_resource_cb was silent at
ERROR level — the failure was only logged once at INFO inside
connect_resources. Downstream consumers that harvest only ERROR-level CLI
output (e.g. dd-source/managed-sync) lost visibility into which dependency
was missing, so dashboards/monitors that skip due to absent SLOs, monitors,
roles, etc. presented as silent failures.

Add a logger.error call mirroring the generic Exception handler so the
failed_connections_dict payload surfaces as
"[<type> - <id>] - missing connections: {...}" in standard output.
Counter, outcome event, and metric tags are unchanged.

#566)

* fix(tests): prevent integration test resource leaks in destination org

Three changes to ensure destination org resources are always cleaned up:

1. GHA workflow: run cleanup reset after every test run (not just failures)
   — `if: failure()` → `if: always()` so passing runs that somehow leave
   resources also trigger a full `datadog-sync reset`.

2. TestCli: wrap sync/migrate test bodies in try/finally so cleanup is
   guaranteed even when mid-test assertions fail, preventing resources from
   accumulating until the standalone test_cleanup test runs later.

3. BaseResourcesTestClass: add one retry to test_resource_cleanup, matching
   TestCli.test_cleanup's existing pattern, so transient dependency-ordering
   API errors don't permanently leak resources.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix(ci): add continue-on-error to post-run cleanup step

The cleanup step now runs `if: always()` but `datadog-sync reset` exits
non-zero when it hits 403s on powerpacks owned by other users in the
destination org. Mark the step continue-on-error so cleanup failures
don't fail the CI job.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix(ci): add pre-test cleanup step using destination creds as source

Stale destination resources (e.g. monitors with different IDs than source)
cause 'Duplicate' 400 errors when tests try to create them. The existing
post-run reset uses SOURCE creds so it only discovers SOURCE IDs, leaving
destination resources with different IDs untouched.

This new pre-test step overrides DD_SOURCE_* to destination credentials so
reset() discovers actual destination resource IDs and deletes them correctly.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix(reset): add source auth options so pre-test cleanup can target destination

The reset command only accepted destination credentials, so its import
step (used to discover resource IDs before deletion) always ran against
the source org. This meant stale destination resources with IDs different
from their source counterparts (e.g. monitors) were never cleaned up.

Adding @source_auth_options lets callers pass destination credentials as
source, so reset discovers and deletes the actual destination IDs.

The CI pre-test cleanup step sets DD_SOURCE_* to destination values and
uses --do-not-backup to skip the backup step, giving the test suite a
clean destination org before each run.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix(logs_archives): handle 400 'already exists' on create by adopting existing archive

When the destination org has a pre-existing archive with the same name
(e.g. a Datadog built-in default that isn't returned by LIST but still
enforces name uniqueness), the POST returns 400 "already exists". Rather
than propagating the error (which sets exception_logged→exit(1)), fall
back to a GET of all destination archives, find the one matching by name,
and adopt it as the destination state for this source ID.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix(monitors,logs_restriction_queries): handle duplicate/already-attached errors on create

monitors: when POST returns 400 "Duplicate of an existing monitor_id:N",
adopt the existing monitor N rather than propagating the error. Monitors
in the destination org may already exist with identical content (e.g.
left from a prior test run teardown or created as a dependency by another
resource's sync), so create_resource needs to be idempotent.

logs_restriction_queries: when adding a role to a restriction query fails
with 400 "already has an attached restriction query", look up which query
currently holds the role (GET /api/v2/roles/{id}/logs/restriction_query),
detach it from there, then attach to the target query. This handles the
case where a previous sync attempt orphaned a restriction query that still
holds the role.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix(logs_restriction_queries): replace broken role-lookup with list-and-scan in _reassign_role

The previous implementation used GET /api/v2/roles/{id}/logs/restriction_query
which is not a valid Datadog endpoint. When it failed the exception was silently
swallowed, then the subsequent add call also failed with "already has an attached
restriction query", causing all role assignments to be skipped.

Replace with a list-and-scan: fetch all destination restriction queries, check
each one's roles list, remove the role from whichever query currently holds it,
then add it to the target. Handles the case where the role is already on the
target (no-op) and where the remove races with a concurrent worker (silently
ignored).

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix(logs_restriction_queries): pass body as keyword arg in remove_log_restriction_query_role

delete(path, domain=None, subdomain=None, body=None) has body as keyword-only,
but the call was passing the payload as the second positional arg (domain).
This caused the URL to be constructed as https://{base}.{payload}/{path},
producing a malformed URL and a connection error instead of a clean API call.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* fix: handle dirty destination idempotency edge cases

---------

Co-authored-by: Claude Sonnet 4.6 <[email protected]>