feat(SYNTH-24202): set synthetics tests as paused by default and manage dr metadata during sync

[aletournel]

Requirements for Contributing to this repository

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue, or add one feature, at the time.
• The pull request must update the test suite to demonstrate the changed functionality.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

Sets synthetics tests to paused status when created on the destination org during sync, and injects disaster recovery metadata to track source test identity and status. (RFC for more context)

Description of the Change

• Added "status" to excluded_attributes so sync diffs don't overwrite manual status changes on the destination
• Force tests to have be paused at creation by setting the status=paused
• pre_resource_action_hook injects metadata.disaster_recovery (with source_public_id and source_status) on every create/update, enabling the system to track source test provenance and trigger updates when
  source status changes
• All GET requests now include ?include_metadata=true to fetch metadata from the API
• Metadata is persisted in local state after create/update so subsequent diffs compare correctly

Verification Process (Follow Runbook to log into Synthetics DDR testing Orgs)

Synced Synthetics Tests from Staging R1 to Staging R2:

• The replicated tests are paused in R2
• Snapshot from the source file synthetics_tests.json:

{"y2j-izg-83s#25601497": {"public_id": "y2j-izg-83s", "name": "Test on datadoghq.com.", "status": "live", "type": "api", "subtype": "http", "tags": ["sadj klsjdf lkjs dfl ;lkj2l3j324(*&", "staging", "prod", "siuefh (soeiuf", "env:staging", "env:prod", "team:athing", "team:synthetics-services", "team:synthetics", "team:core-incident-commanders", "managed_by:datadog-sync", "managed_by:datadog-sync"]}

• Snapshot from the destination file synthetics_tests.json with status=paused and metadata.disaster_recovery:

{"y2j-izg-83s#25601497": {"public_id": "qed-4qj-p8n", "name": "Test on datadoghq.com.", 
"status": "paused", "type": "api", "subtype": "http", "tags": ["sadj klsjdf lkjs dfl ;lkj2l3j324(*&", "staging", "prod", "siuefh (soeiuf", "env:staging", "env:prod", "team:athing", "team:synthetics-services", "team:synthetics", "team:core-incident-commanders", "managed_by:datadog-sync"], "created_by": {"name": "Malak El kouri", "handle": "malak.elkouri@datadoghq.com", "email": "malak.elkouri@datadoghq.com"}, "deleted_at": null, "monitor_id": 25683742, "org_id": 479277, "modified_by": {"name": "Malak El kouri", "handle": "malak.elkouri@datadoghq.com", "email": "malak.elkouri@datadoghq.com"}, 
"metadata": {"disaster_recovery": {"source_public_id": "y2j-izg-83s", "source_status": "live"}}}

Additional Notes

Integration test cassettes were updated to reflect:

• ?include_metadata=true query param on GET requests
• POST bodies: status removed by prep_resource, re-added as "paused" at end by create_resource, metadata appended
• PUT bodies: status removed by prep_resource (not re-added), metadata appended

Review checklist (to be filled by reviewers)

• Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• PR title must be written as a CHANGELOG entry (see why)
• Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• PR should not have do-not-merge/ label attached.
• If Applicable, issue must have kind/ and severity/ labels attached at least.

[michael-richey]

I know you're still working on this, but thought I'd chime in. Customers have brought up this problem with monitors. If they have monitor A, B, and C in R1 and B is muted in R1. Then if we copy A, B, and C to R2 and mute all 3 of them. How do they know which monitors to unmute? (This is solved by global downtime, monitors themselves keep their muted/unmuted status during a copy)

I'm worried the same might happen with synthetics. Synthetics A, B, and C exist in R1 and B is paused. If we pause A, B, and C in R2 how does the customer know to only unpause A and C? My quick suggestion would be tags if we can tag tests at all? If the R1 test is paused just copy it over as is, but if the R1 test is running and sync-cli forcibly pauses it we could add a tag like paused_by:datadog-sync-cli. We also may need to remove that tag in R2 if they end up pausing the test in R1.

[aletournel]

👋 Hey Michael,

Thanks for taking a peek, yes it is a rough first draft as I wanted to have a quick proof of concept that it work as expected but I need to add unit tests at the very least.

And to get back to your questions, yes you're definitively right that we need to make the distinction between paused tests in R1 and live tests in R1. And by pausing all the synced tests in R2 we lose that distinction.

This is why as you've already guess we need extra metadata as well. Tags are an option as we do tag tests. But in the RFC, we think for future it's best to have both the source_status and the source_public_id. And after discussing with folks managing the Synthetics API and the data model suggested in the RFC, we have planned as of today to use a new dedicated field for this so that the metadata can be enrich for the Edge DCs.

Those metadata will get set and updated by datasync but will not be visible on Synthetics UI out of the box unlike tags. But we could add a banner to say "This test in managed by datadog-sync-cli and is a replication of test X in dc Y. It will be unpaused automatically during a DDR failover event".

[aletournel]

I've been meaning to ask though if should put this behavior (Pausing the s8s test on creation + and keeping metadata up to date) behind a flags like datadog-sync sync --ddr --config config or a dedicated command like datadog-sync ddr-sync --config config. Because in case datadog-sync is used to migrate a customer from one DC to another we may not want this behavior.

[michael-richey]

👋 Hey Michael,

Thanks for taking a peek, yes it is a rough first draft as I wanted to have a quick proof of concept that it work as expected but I need to add unit tests at the very least.

And to get back to your questions, yes you're definitively right that we need to make the distinction between paused tests in R1 and live tests in R1. And by pausing all the synced tests in R2 we lose that distinction.

This is why as you've already guess we need extra metadata as well. Tags are an option as we do tag tests. But in the RFC, we think for future it's best to have both the source_status and the source_public_id. And after discussing with folks managing the Synthetics API and the data model suggested in the RFC, we have planned as of today to use a new dedicated field for this so that the metadata can be enrich for the Edge DCs.

Those metadata will get set and updated by datasync but will not be visible on Synthetics UI out of the box unlike tags. But we could add a banner to say "This test in managed by datadog-sync-cli and is a replication of test X in dc Y. It will be unpaused automatically during a DDR failover event".

Yeah, anything for the users to know what was running/paused in R1 would be good.

[michael-richey]

I've been meaning to ask though if should put this behavior (Pausing the s8s test on creation + and keeping metadata up to date) behind a flags like datadog-sync sync --ddr --config config or a dedicated command like datadog-sync ddr-sync --config config. Because in case datadog-sync is used to migrate a customer from one DC to another we may not want this behavior.

Our policy (while not overly popular) has been to treat sync-cli's default behavior as a tool for DDR, and build in flags to allow migration unrelated to DDR. So I'd say have the tests pause by default and provide a flag like --retain-synthetic-tests-state to stop that behavior.

[melkouri]

/integrate

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-02-17 13:10:17 UTC ℹ️ Start processing command /integrate

---

2026-02-17 13:10:24 UTC ❌ Integrate failure

No services specified for deployment and BIA didn't detect any impacted services

[michael-richey]

The PR and testing look good.