Skip to content

Read Datadog monitors stored as objects - #125

Merged
ryanduffin merged 4 commits into
mainfrom
rduffin/datadog-monitor-objects
Oct 6, 2026
Merged

ryanduffin merged 4 commits into
mainfrom
rduffin/datadog-monitor-objects

Conversation

@ryanduffin

@ryanduffin ryanduffin commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

cortex_catalog_entity no longer crashes when an entity's Datadog monitors are stored as objects.

Claude Details

Summary

  • The Cortex API accepts a Datadog monitor as a bare ID (- 123) or as an object with an ID and an optional alias (- id: 123). The object form came with Datadog multi-account support.
  • The parser read only the bare form. An unchecked type assertion (monitor.(int)) panicked on the object form, so plan, apply, and refresh crashed for any entity with object-form monitors.

Changes

  • interpolateDataDogApm reads both forms through a new dataDogMonitorID helper. interpolateApm and interpolateDataDogApm now return an error, as interpolateSLOs already does.
  • IDs are parsed as integers (int, int64, or a base-10 string inside an object), not through float64. Fractions, infinity, and values outside the int64 range are errors.
  • The rules follow the backend parser:
    • A bare string monitor is an error. The API converts a string ID only inside an object and drops a bare string.
    • Every non-null alias is an error, including "", which the API treats as an alias name. The schema has no alias attribute, so reading only the ID would drop the alias on the next apply, and the monitor would move to the default Datadog configuration without a message. The error tells the user to remove the alias in Cortex.
  • A Datadog APM value that is not an object, or monitors that is not a list, is an error, not a panic.
  • GetFromDescriptor adds the entity tag to parse errors, so the user can see which entity failed.
  • CHANGELOG entry.

Not in this PR

  • Alias support in the schema. This needs a new attribute, because a change to the type of monitors would break current configurations.
  • Other unchecked casts in the parser (for example the New Relic applicationId, the SLO maps, and the top-level section casts in YamlToEntity) can still panic on unexpected input.

Test plan

  • go test ./...: all packages pass.
    • TestYamlToEntityReadsDatadogMonitorsAsObjects: before the fix, it panics with interface {} is map[string]interface {}, not int. After the fix, mixed bare and object monitors read as IDs.
    • TestYamlToEntityReadsDatadogMonitorsAsIntegers: includes an ID above 2^53, which reads exactly.
    • TestYamlToEntityRejectsDatadogMonitorWithAlias: string, number, boolean, and empty aliases.
    • TestYamlToEntityRejectsDatadogMonitorWithoutIntegerID: null, missing ID, bare string, non-integer string, fraction, exponent, infinity, out of range, and nested list. Each case checks its own message.
    • TestYamlToEntityRejectsMalformedDatadogApm and TestGetFromDescriptorNamesEntityInParseError.
  • gofmt -l, go vet ./..., and golangci-lint run (v2.14.0): clean.
  • make testacc: not run locally. CI runs it.

🤖 Generated with Claude Code

The API stores a Datadog monitor as a bare ID or as an object with an
ID and an optional alias. The provider read only the bare form, and an
unchecked type assertion crashed the provider during plan, apply, and
refresh for any entity with object-form monitors.

The parser now reads both forms. A monitor with an alias, or without a
numeric ID, returns an error instead of a panic. The schema has no
alias attribute, so reading the ID alone would drop the alias on the
next apply.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@ryanduffin
ryanduffin added this pull request to stack #128 October 6, 2026 15:30
@ryanduffin
ryanduffin marked this pull request as ready for review October 6, 2026 18:33
ryanduffin and others added 3 commits October 6, 2026 14:38
The alias check read only string aliases, but the API also accepts a
number or a boolean as an alias. Any non-empty alias is now an error,
and the message says how to fix it.

Monitor IDs are now parsed as integers, not through float64, so
infinity, values out of the int64 range, and IDs above 2^53 no longer
read as wrong IDs. A string ID is parsed as a base-10 integer.

A Datadog APM value that is not an object, or monitors that are not a
list, is now an error instead of a panic. GetFromDescriptor adds the
entity tag to parse errors, so the user can see which entity failed.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The API drops a bare string monitor and converts a string ID only
inside an object, so a bare string is now an error instead of an ID
that Cortex never registers. The API also treats an empty alias as an
alias name, so every non-null alias is now an error.

The alias error now reports the parsed ID, and the error for a
non-integer ID names the decoded type.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@ryanduffin
ryanduffin merged commit 0be883d into main Oct 6, 2026
9 of 10 checks passed
@ryanduffin
ryanduffin deleted the rduffin/datadog-monitor-objects branch October 6, 2026 20:43
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