Internal ping check resources created via CreateAsync have 0 DataSources applied (missing ?type=uptimepingcheck)

[davidnmbond]

Summary

CreateAsync(ResourceCreationDto) with ResourceType = ResourceType.Ping (deviceType 19 / uptimepingcheck) creates the resource successfully, but DS 4901 (Ping_Check_Individual) and DS 4902 (Ping_Check_Overall) are never applied and system.uptime.type is absent from system properties. The resource appears in the portal with a greyed-out toolbar and 0 graphs.

Root Cause

The LM server requires the URL query parameter ?type=uptimepingcheck to trigger server-side initialization of internal ping check resources. Without it:

• system.uptime.type = internal is not set in system properties
• predef.externalResourceType = PingCheck is not set in auto-properties
• DS 4901/4902 are never applied (even after days)

The official LogicMonitor PowerShell module (New-LMUptimeDevice) correctly appends ?type=uptimepingcheck to the URL:

$uri = "https://$($Script:LMAuth.Portal).$(Get-LMPortalURI)$resourcePath`?type=$apiType"
# → POST /device/devices?type=uptimepingcheck

Evidence

API-created resource (buggy, via CreateAsync without the query parameter):

"systemProperties": [
  { "name": "system.device.provider", "value": "Uptime" }
  // system.uptime.type is ABSENT
],
"autoProperties": []

DS 4901/4902: 0 applied — confirmed after multiple days

Correctly created resource (with ?type=uptimepingcheck):

"systemProperties": [
  { "name": "system.uptime.type", "value": "internal" }
],
"autoProperties": [
  { "name": "predef.externalResourceType", "value": "PingCheck" },
  { "name": "auto.resourceTypeCategory", "value": "Networking" }
]

DS 4901 + 4902: applied immediately at creation time ✅

Workaround (confirmed working)

Send a raw HMAC-signed POST /device/devices?type=uptimepingcheck. Note the body is much simpler than what the wire mapper currently sends — no need to manually set website.private.* properties, system.categories, or checkpoints; the server generates them all:

{
  "id": 0,
  "type": "uptimepingcheck",
  "model": "websiteDevice",
  "deviceType": 19,
  "name": "my-ping-check",
  "displayName": "my-ping-check",
  "isInternal": true,
  "groupIds": ["532"],
  "pollingInterval": 10,
  "host": "192.168.1.1",
  "count": 5,
  "percentPktsNotReceiveInTime": 80,
  "timeoutInMSPktsNotReceive": 500,
  "transition": 1,
  "overallAlertLevel": "warn",
  "individualAlertLevel": "warn",
  "individualSmAlertEnable": false,
  "useDefaultAlertSetting": true,
  "useDefaultLocationSetting": false,
  "globalSmAlertCond": 0,
  "testLocation": { "collectorIds": [3], "smgIds": [] },
  "properties": []
}

HMAC signing: sign against /device/devices (without the query string), per the LM API signing spec.

Fix Required

In UptimeResourceWireMapper (or wherever the POST URL is constructed for CreateAsync with ResourceType.Ping), append ?type=uptimepingcheck to the URL. For web uptime checks (ResourceType.Web / deviceType 18), similarly append ?type=uptimewebcheck.

The request body can also be simplified significantly — the website.private.* properties, system.categories, uptime.hostname, etc. that the wire mapper currently sets are generated server-side when the correct query parameter is present. They are redundant.

Secondary Issues Found in Integration Tests

• UptimePingCheckResourceTests.cs and PingCheckResourceTests.cs do not assert DS application, system.uptime.type, or autoProperties — so this bug passes all existing tests silently.
• Tests use TestLocation.All = false but the UI and New-LMUptimeDevice use All = true for internal checks.

Environment

• LogicMonitor.Api 3.240.7
• Confirmed against a production LogicMonitor portal
• Discovered while doing a bulk migration of 694 ping-only resources to internal ping checks