bug: api_debug omits V2 App Platform HTTP requests
- Dominant language
- Go
- Stars
- 428
- Forks
- 40
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 27
Description
## Before Opening a Bug did you?
- Look at the [FAQ](https://software.es.net/gdg/docs/gdg/frequently-asked-questions/)
- Configuration Documentation found [here](https://software.es.net/gdg/docs/gdg/configuration/)
- Did you look at the [example](https://github.com/esnet/gdg/blob/main/config/gdg-example.yml) config?
All yes
**Describe the bug**
`api_debug: true` doesn't show all the HTTP logs.
**To Reproduce**
Steps to reproduce the behavior:
1. Set `api_debug: true`
2. Run `gdg backup dash d`
3. Observe the logs. The dashboards download, but are absent in the logs
**Expected behavior**
All the HTTP requests and responses should be logged, if `api_debug` is set to `true`
**Debugging Data (please complete the following information):**
Please provide the output of the following commands:
1. gdg version
```sh
2026-09-03 16:00:12 INF Build Date: 2026-03-05T18:47:37Z
2026-09-03 16:00:12 INF Git Commit: 8e2d4c107bfab2bd94823eb387d919b8e060ed8b
2026-09-03 16:00:12 INF Version: v0.9.3
2026-09-03 16:00:12 INF Go Version: go1.26.0
2026-09-03 16:00:12 INF OS / Arch: linux amd64
```
2. gdg tools devel srvinfo (If you are able to connect to your grafana instance)
```sh
2026-09-03 16:00:24 INF tools/devel.go:31 Database=ok
2026-09-03 16:00:24 INF tools/devel.go:31 Commit=a9cee6e1724a455676bb6c05eef7fc54aa4b19f4
2026-09-03 16:00:24 INF tools/devel.go:31 Version=13.1.1
2026-09-03 16:00:24 INF tools/devel.go:31 EnterpriseCommit=""
```
3. Redacted output of: gdg tools contexts show (Or include your config )
```yaml
config file: /home/dev/gdg/config/gdg.yml
---context: mycontext
connections:
credential_rules:
- rules:
- field: name
regex: .*
secure_data: auth_mycontext.yaml
dashboard_settings:
ignore_filters: true
watched:
- General
watched_folders_override: []
organization_name: Main Org.
secure_location: ""
output_path: dst_folder
storage: ""
url: http://localhost:3000
user_name: admin
user: null
```
4. Are you using Local storage? Cloud S3 buckets? Which cloud provider are you using? Please share as much of your config as you can with any secrets redacted.
Only local storage is used. Global settings:
```yaml
global:
debug: true
api_debug: true
ignore_ssl_errors: false
retry_count: 3
retry_delay: 5s
clear_output: true
```
**Additional context**
**Root Cause Analysis:**
When `api_debug: true` is enabled, HTTP request and response dumps are logged for legacy V1 endpoints, but V2 App Platform API calls (e.g., `uploadDashboardsV2`, `listDashboardsV2`) are completely omitted from the debug output. Additionally, ad-hoc API handlers (such as `orgs.go`) log raw Go struct pointers (e.g., `&{{http://...}}`) via manual `log.Printf` calls instead of formatted wire dumps.
This occurs because GDG uses three distinct HTTP client mechanisms:
1. **V1 Legacy API (`grafana-openapi-client-go`):** Relies on `go-openapi/runtime` and standard `http.Client`.
2. **V1 Ad-hoc Endpoints (`carlmjohnson/requests`):** Uses custom `http.Transport` clones or `http.DefaultTransport`.
3. **V2 App Platform API (`k8s.io/client-go`):** Initialized via `k8sRestConfig()` in `dashboards_v2_client.go`. `client-go` constructs its own isolated `http.Transport` stack, which completely bypasses GDG's global debug logging flags and `http.DefaultTransport`.
**Proposed Solution:**
Centralize HTTP request/response debugging by implementing a standard Go `http.RoundTripper` middleware (`DebugLoggingTransport`) using `httputil.DumpRequestOut` and `httputil.DumpResponse` when `api_debug` is enabled:
1. Attach a configured `*http.Client` / `http.RoundTripper` instance to `GDGAppConfiguration` at application startup.
2. Inject this central transport into `k8s.io/client-go` via `cfg.WrapTransport` inside `k8sRestConfig()`.
3. Reuse the central client across V1 and ad-hoc HTTP endpoints.
4. Remove manual `log.Printf` struct dumps in adapter files to keep debug logging uniform.
I would be happy to take this on and submit a PR. Let me know if this approach looks good or if you'd prefer a different direction!
Contributor guide
Assessment
This issue has not been assessed yet.