You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Symptom: Every dynatrace command (services, workloads, entities list/get, problems list/get, trace) and config test/config check's dynatrace probe fail with HTTP 404 Not Found, even with valid credentials. Requests are sent to https://<host>/api/v2/entities instead of https://<host>/e/<environment-id>/api/v2/entities, silently dropping the /e/<environment-id> path segment of the configured base URL. This affects any Dynatrace Managed (self-hosted, multi-environment) cluster — SaaS single-tenant URLs (https://abc12345.live.dynatrace.com, no path component) are unaffected.
Repro:pncli dynatrace services --from now-2h with dynatrace.baseUrl = https://dynatrace.imagile.dev/e/abc12345-0000-0000-0000-000000000000 → {"ok":false,"error":{"status":404,"message":"HTTP 404 Not Found","url":"https://dynatrace.imagile.dev/api/v2/entities?..."}}. Confirmed the cluster receives and routes the request (response header Dynatrace-Response-Source: Cluster), it just can't resolve which environment without the path segment.
Expected: Request should go to https://dynatrace.imagile.dev/e/abc12345-0000-0000-0000-000000000000/api/v2/entities.
Notes: This is the exact same root cause as BUG-4 (artifactory baseUrl-with-path bug, fixed post-v1.7.0 in PR fix(artifactory): preserve base URL path component when building request URLs #94): src/lib/http.ts's shared buildUrl() calls new URL(path, base) where path starts with / (e.g. /api/v2/entities). Per the WHATWG URL spec, an absolute path resolves relative to the origin, discarding any path component already present in base. Confirmed via node -e "new URL('/api/v2/entities', 'https://host/e/xyz/').toString()" → https://host/api/v2/entities (env segment dropped), vs. stripping the leading slash from path before resolving → correctly preserves it. BUG-4 was fixed by removing the leading slash from the Artifactory client's path constants rather than fixing buildUrl() itself, so the underlying flaw was never eliminated and has now resurfaced in src/services/dynatrace/commands.ts, which builds every endpoint path as /api/v2/... or /platform/.... Recommend fixing buildUrl() itself this time (e.g. strip a single leading / from path before combining) so future services with path-bearing base URLs don't hit the same bug again.
db99b92)dynatracecommand (services,workloads,entities list/get,problems list/get,trace) andconfig test/config check's dynatrace probe fail withHTTP 404 Not Found, even with valid credentials. Requests are sent tohttps://<host>/api/v2/entitiesinstead ofhttps://<host>/e/<environment-id>/api/v2/entities, silently dropping the/e/<environment-id>path segment of the configured base URL. This affects any Dynatrace Managed (self-hosted, multi-environment) cluster — SaaS single-tenant URLs (https://abc12345.live.dynatrace.com, no path component) are unaffected.pncli dynatrace services --from now-2hwithdynatrace.baseUrl = https://dynatrace.imagile.dev/e/abc12345-0000-0000-0000-000000000000→{"ok":false,"error":{"status":404,"message":"HTTP 404 Not Found","url":"https://dynatrace.imagile.dev/api/v2/entities?..."}}. Confirmed the cluster receives and routes the request (response headerDynatrace-Response-Source: Cluster), it just can't resolve which environment without the path segment.https://dynatrace.imagile.dev/e/abc12345-0000-0000-0000-000000000000/api/v2/entities.artifactorybaseUrl-with-path bug, fixed post-v1.7.0 in PR fix(artifactory): preserve base URL path component when building request URLs #94):src/lib/http.ts's sharedbuildUrl()callsnew URL(path, base)wherepathstarts with/(e.g./api/v2/entities). Per the WHATWG URL spec, an absolute path resolves relative to the origin, discarding any path component already present inbase. Confirmed vianode -e "new URL('/api/v2/entities', 'https://host/e/xyz/').toString()"→https://host/api/v2/entities(env segment dropped), vs. stripping the leading slash frompathbefore resolving → correctly preserves it. BUG-4 was fixed by removing the leading slash from the Artifactory client's path constants rather than fixingbuildUrl()itself, so the underlying flaw was never eliminated and has now resurfaced insrc/services/dynatrace/commands.ts, which builds every endpoint path as/api/v2/...or/platform/.... Recommend fixingbuildUrl()itself this time (e.g. strip a single leading/frompathbefore combining) so future services with path-bearing base URLs don't hit the same bug again.Service: Other
Submitted via kolatts.github.io/pncli