Issue with folder names containing spaces when downloading the Dashboard using GDG following v0.8.1 release

[techuser12345]

Issue with folder names containing spaces when downloading the Dashboard using GDG.

GDG is handling the space in the folder name by encoding the characters differently each time I download the same original folder with a space in the folder name.

GDG v 0.8.1
Grafana v11.2.0

I think it's related to
79f8985
Minor tweaks dealing with folders containing spaces (#455)

example
"Monthly Incidents" to "Monthly+Incidents" to "Monthly%2BIncidents" to "Monthly%252BIncidents"

[csg33k]

0.8.1 Should allow for a more flexible pattern, especially with nested folder becoming a standard feature, but it does make spacing a bit troublesome. Mostly since it gets encoded with a + separator which needs to be escaped as it's a valid special char.

I thought I added a proper test for this and crud.

Can tell me when you're getting the inconsistencies.

For my part given this regex in the config:

        watched:
            - ES\+net/LHC\+Data\+Challenge

will consistently writes the output to:

test/data/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json

And list it as:

┌────┬─────────────────┬─────────────────┬────────────────────┬───────────────────────────┬───────────┬──────┬───────────────────────────────────────────────────┐
│ ID │ TITLE           │ SLUG            │ FOLDER             │ NESTEDPATH                │ UID       │ TAGS │ URL                                               │
├────┼─────────────────┼─────────────────┼────────────────────┼───────────────────────────┼───────────┼──────┼───────────────────────────────────────────────────┤
│  3 │ Firefly Details │ firefly-details │ LHC Data Challenge │ ES+net/LHC+Data+Challenge │ JywX0Qt7k │      │ http://localhost:3000/d/JywX0Qt7k/firefly-details │
└────┴─────────────────┴─────────────────┴────────────────────┴───────────────────────────┴───────────┴──────┴───────────────────────────────────────────────────┘

Can you tell me a bit more on what you're doing? Any sequence of operations?

Also if you can share the output of:

gdg tools devel srvinfo && your config (minus token/password) that'd be great.

[csg33k]

@techuser12345 final poke before I close this out. Any updates/feedback?

[techuser12345]

Thanks for following up. Yes, I’m still seeing the issue — it seems to be caused by recursive encoding of folder names containing spaces.

For example, when I export dashboards from UAT using GDG (v0.8.1), a folder like:

"Monthly Incidents" becomes
"Monthly+Incidents" → then
"Monthly%2BIncidents" → then
"Monthly%252BIncidents"
Each time I export, the + gets re-encoded to %2B, and then the % gets re-encoded to %25, leading to nested encoding. So the folder name keeps getting messier with each run.

I'm using GDG in UAT to extract dashboards and then push only the extracted JSON into Git (stash), which is later provisioned in production. Because the folder name keeps changing, it creates inconsistencies and breaks the provisioning setup.

I had a downgrade the version and had to fix all the folder names

Let me know if you'd like any further information.

[csg33k]

So, starting with 0.8.1 the having a folder named: "Monthly Incidents" would get encoded as "Monthly+Incidents".

That's expected behavior. I'm using the test data I have in git mostly since it's available to me. If you could share the full nested path you're using that would be helpful as well.

Just far a sanity check:

version:

2025-07-26 11:44:56 INF Build Date: 2025-06-30T22:04:17Z
2025-07-26 11:44:56 INF Git Commit: 92631bd66442cdd0cb3f456a18f1c86971fdd0bc
2025-07-26 11:44:56 INF Version: v0.8.1
2025-07-26 11:44:56 INF Go Version: go1.24.4
2025-07-26 11:44:56 INF OS / Arch: darwin arm64

config: gdg tools contexts show

---testing:
token: ""
connections:
    credential_rules:
        - rules:
            - field: name
              regex: .*
          secure_data: default.json
dashboard_settings: null
watched:
  - ES\+net
watched_folders_override: []
organization_name: ""
secure_location: ""
output_path: test/data
password: admin
storage: ""
url: http://localhost:3000
user_name: admin
user: null

so local filesytem has: test/data/org_main-org/dashboards/ES+net/LHC+Data+Challenge

Naturally both "ES net" and "LHS Data Challenge" have spaces.

Upload works fine and find the file.

I've repeatedly uploaded and downloaded the data. Maybe it's just a matter or deleting the old data that had a space in the folder path?

IF I intemix the backup behavior of both 0.7.2 and 0.8.1 then I get some issues.

1. The UID will be duplicated since they match two different files so one of them will be ignored.

If I fix one of export file to have a different UID for testing purposes:

Case A:
you have a proper regex for the folder space, everything works as expected. The "ES Net" is ignored since it never matches the correct regex you should be using which is: ES\+net or some variation of that.

Case B:
you're using wild card behavior, in which case gdg will consider both of them since the regex is never triggered, both paths are created:

┌──────────────────────────────────────────────────────────────────────────────────┐
│ FILE                                                                             │
├──────────────────────────────────────────────────────────────────────────────────┤
│ test/data/org_main-org/dashboards/ES net/LHC Data Challenge/firefly-details.json │
│ test/data/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json │
└──────────────────────────────────────────────────────────────────────────────────┘

In grafana you now have duplicate folders with the same name.

But.. if you try to pull them down both will be written to the same path, it'll encode both of them as the exact same pattern and write the data to the same path.

┌───────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ TYPE      │ FILENAME                                                                         │
├───────────┼──────────────────────────────────────────────────────────────────────────────────┤
│ dashboard │ test/data/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json │
│ dashboard │ test/data/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json │
└───────────┴──────────────────────────────────────────────────────────────────────────────────┘

Different folders with different name and exact same nested path is not supported and I would expect it to break.

There's a global that you can set called: clear_output that will clear out the backup location before downloading that might help you.

global:
    clear_output: true

or manually delete your dashboards export and pull them from your source of truth using 0.8.1 and it looks like everything should work to me.

If you give me more info I can try to debug this, but I can't reproduce your specific use case.

1. I really think this issue is you needing to cleanup old data in your exports.
2. Same name for same path in not supported, though GDG could handle that use case better, it's such an bizarre edge case that I'm not sure is we need the logic to handle it.
3. I'm not able to re-create the circular encoding you mentioned, so if you wan share your config, export paths... steps involved in getting that behavior I can dig into it more. OS, environment? are you running this using docker? K8s? local?

[techuser12345]

Thanks for the follow-up. Just to confirm:

When I was using GDG v0.8.1, my config included:

`context_name: grafana-sync
storage_engine:
      any_label:
             bucket_name: ""
             cloud_type: s3
             kind: cloud
      custom_cloud:
            access_id: ""
            bucket_name: mybucket
            cloud_type: s3
            endpoint: http://localhost:9000
            init_bucket: "true"
            kind: cloud
            prefix: dummy
            secret_key: ""
            ssl_enabled: "false"
contexts:
       grafana-sync:
             token: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
             connections: null
             dashboard_settings:
                     nested_folders: true
                     ignore_filters: true
             watched:
                     - General
             watched_folders_override: []
             organization_name: "Main Org."
             secure_location: ""
             output_path: /path/to/grafana/gdg/output
             password: ""
             storage: ""
             url: https://sdfsdfsdsds.sdfs.sdf.dsfsd.dfs:3000/grafana
             user_name: ""
             user: null
global:
       debug: true
       api_debug: false
       ignore_ssl_errors: false
       retry_count:3
       retry_delay: 5s
       clear_output: true`

I don't use cloud/s3, just linux server.
In UAT, users create or modify dashboards/folders directly in the Grafana UI.
When they’re ready to promote to prod, they manually trigger a bash-based sync job via Rundeck, which:

1. Runs on the UAT server using GDG to export dashboards only
2. Pushes the exports to Stash
3. The exported dashboards /grafana/dashboards/ are then packaged and provisioned in both UAT and Prod

I'm only exporting dashboards (not datasources or folders) or anything else.
Folder names often include spaces or special characters.
Despite clear_output: true, I still saw recursive encoding of folder names with spaces (e.g., "Monthly Incidents" → + → %2B → %252B and so on similarly folder name with & become '%26' > '%2526B' > '%252526B' and so on).
Running on a Linux server using SQLite.

I was originally looking for a solution for library panels #286 (reply in thread) , which is why I upgraded to the latest GDG. Please advise, given my current setup.

[safaci2000]

I'll try to test this on a linux server next week.

For what it's worth, nested_folders is deprecated and no longer needed. The watched folder also likely doesn't need to be set.

What steps are followed though.

so you have an instance running that's UAT.

I need to translate your pipeline into GDG steps.

1.Runs on the UAT server using GDG to export dashboards only
that's gdg backup dashboard downloand correct? where UAT is the context ?
2. Pushes the exports to Stash (What does that mean? point to new context and push? )
3. The exported dashboards /grafana/dashboards/ are then packaged and provisioned in both UAT and Prod
(Using GDG? Some other tool?)

[techuser12345]

Thanks for the reply and clarification.

Yes, my GDG context is named grafana-sync, and to clarify the workflow:

Users create or modify dashboards directly in the Grafana UI in UAT.

When they're ready to promote to production, they manually trigger a Rundeck job, passing a Jira ticket ID as an argument.

That job:

1. Runs on the UAT server
2. Uses GDG (gdg backup dashboard download) with context grafana-sync to export dashboards only (not folders or datasources)
3. Saves the exports under /grafana/dashboards/
4. Creates a pull request (feature branch) with all exported dashboards placed under grafana/dashboards/

This path is used for Grafana provisioning in both UAT and Prod (via dashboard.yml in Grafana config).

I use GDG only on the UAT server, and only for exporting dashboards.

By “pushes to Stash,” I mean the exported dashboards are committed and pushed to Git (Bitbucket/Stash) — no GDG context switching or push between instances.

While I originally upgraded to the latest GDG version to resolve the library panel issue (#286), I haven't been able to address that yet — I'm first trying to sort out the encoding issue.

Specifically, with clear_output: true enabled, I was still seeing recursive encoding of folder names containing spaces or special characters:

"Monthly Incidents" → + → %2B → %252B
"IT & Ops" → %26 → %2526 → %252526
Let me know if you'd like any additional details — happy to share.

[safaci2000]

I'm going to set up a basic linux to validate your issue.

Thank you for sharing all of the workflow ...so if I understand this correctly...

1. gdg b dash download (is executed for UAT to import)
2. pull request export the data to: Prod. gdg b dash upload
3. If I'm not mistaken you have ignore_filters set to true in your GDG contexts, correct?

At this point, some pattern to try that would be nice would be:

1. renaming the dashboard export temporarily if you want to test out 0.8.1. Get a fresh pull from UAT.
2. I still don't get how you're getting the repetitive encoding. (I'll see on linux host if it's different)

Basically as far as I can tell you have a host/VM where you'll only pulling from UAT using GDG, writing to the same path and only exporting to Prod.

So I'm really confused on how you're getting different encoding.

Are you saying just running gdg backup dash download repeatedly without changing anything keeps giving you multiple encoded paths?

If that's the case the problem is clear.. it's doesn't make sense why it would work that way, but if I can recreate the issue, I'll get a fix out.

If you can confirm the assumptions I've made that'd be great.

I assume this would not matter much, but if you can give me an exact OS version that'd be great.

x86 vs 64, etc.

Also, those folder Encoding you're seeing, I'm assuming those issues are on the file system exports, not i grafana itself, is that correct?

[techuser12345]

Thanks again for the detailed response and for taking the time to validate this on Linux.

To confirm your assumptions and add full context on my end:

If I'm not mistaken you have ignore_filters set to true in your GDG contexts, correct? - Yes, that's right. I've supplied the full file in one of my previous replies.

Workflow Summary

1. I run the following commands on the UAT server:

./gdg tools ctx set grafana-sync
./gdg tools ctx list
./gdg backup dash download

2. This imports all dashboards from Grafana into the local file system.

3. After export, I run:

cp -rp ./gdg/output/org_main-org/dashboards ./gdg/output/grafana/

4. Then, I use the Bitbucket API to create a feature branch and auto-generate a pull request, placing all exported dashboards under grafana/dashboards/.
5. The PR is reviewed and approved (even if only one dashboard was modified, the export refreshes all of them, causing version bumps, which can make PR review noisier, but is manageable).
6. Once approved, the build runs, packages everything, and is deployed:

a. First to UAT
b. Then to Prod — both using Grafana file-based provisioning, not GDG upload.

Provisioning Setup

1. Datasources are managed in:
   ./grafana/conf/provisioning/datasources/datasources.yml

apiVersion: 1
deleteDatasources:
  - name: Prometheus
    orgId: 1
datasources:
  - name: Prometheus
    type: prometheus
    uid: prometheus
    access: proxy
    orgId: 1
    url: https://${host}:${port}/prometheus
    version: 1
    editable: false

2. Dashboards are provisioned using:
   ./grafana/conf/provisioning/dashboards/dashboards.yml

apiVersion: 1
providers:
  - name: 'bitbucket provider'
    orgId: 1
    folder: ''
    folderUid: ''
    type: file
    disableDeletion: false
    updateIntervalSeconds: 10
    allowUiUpdates: true
    options:
      path: grafana/dashboards
      foldersFromFilesStructure: true

Key Issue Recap

1. Despite using clear_output: true, I still see recursive encoding when running gdg backup dashboard download multiple times without any changes in Grafana.
2. Example:
   "Monthly Incidents" → Monthly+Incidents → Monthly%2BIncidents → Monthly%252BIncidents
"IT & Ops" → IT%26Ops → IT%2526Ops, and so on
3. These encoding changes appear first in the exported file paths, but since we use file-based provisioning, they also end up in the Grafana UI as deeply encoded folder names.

Environment Info

1. OS: Red Hat Enterprise Linux release 8.9 (Ootpa)
2. Architecture: x86_64
3. GDG runs directly on this host (not containerised)

Please let me know if you require any additional information.

[safaci2000]

I don't have the cycles to look at this right now, but one question. Have you tried "rm -fr ./gdg/output/grafana/" before you copy the data over? The whole reason for doing the clear_output was to clear the output destination. If you're manually copying data that you may end up with old folders and JSON that could be causing issues.

If you can try that, it would be nice. As far as the recap, it's very clear now that you're doing and where you're seeing the issues.

I'll setup a test VM at somepoint and will try to recreate the behavior.

[techuser12345]

Thanks for the suggestion. For clarity, here’s exactly what my Rundeck job does each run:

# 1) Fresh clone of repo into ./gdg/output/grafana
git clone <repo-url> ./gdg/output/grafana

# 2) Wipe the dashboards subtree inside the clone
rm -rf ./gdg/output/grafana/dashboards

# 3) Set and verify context
./gdg tools ctx set grafana-sync
./gdg tools ctx list

# 4) Export ALL dashboards from UAT to the GDG export path
./gdg backup dashboard download

# 5) Move General dashboards into Common
mv ./gdg/output/org_main-org/dashboards/General/* \
   ./gdg/output/org_main-org/dashboards/Common/

# 6) Create feature branch (Bitbucket API later creates the PR)

# 7) Copy the fresh export into the repo clone
cp -rp ./gdg/output/org_main-org/dashboards \
       ./gdg/output/grafana/

# 8) Clean up the GDG export source tree (so it doesn’t linger)
rm -rf ./gdg/output/org_main-org/dashboards

# 9) Commit and push from inside the repo clone
cd ./gdg/output/grafana
git add -A
git commit -m "Sync dashboards from UAT"
git push origin <feature-branch>

# 10) Create PR via Bitbucket API token (automated)

# 11) Final cleanup of working dirs
cd -
rm -rf ./gdg/output/grafana
rm -rf ./gdg/output/.git

Key points:

• I do clear the copy target (./gdg/output/grafana/dashboards) at the start of each run.
• I also remove the GDG export source path (./gdg/output/org_main-org/dashboards) at the end of the job, so nothing stale is left behind.
• Despite this, repeated ./gdg backup dashboard download runs (with no Grafana-side changes) still lead to progressively encoded folder names in the filesystem export, which then surface in Grafana via provisioning.

[safaci2000]

Okay, I set this up a ubuntu VM.

initial setup:

1. I uploaded all my usual dashboards to a grafana matching your version:
2. I created a folder manually named: "Monthly Incidents" and moved a few dashboards in there.
3. Changed the output to test/bug

A few notes:

1. Try using gdg --context instead os gdg tools context set, it's a bit cleaner since set re-write your config file to make that change (avoid potential issues)

My bug testing config:

---testing:
token: glsa_ymSeMMlooN6c2U5bAYOdRmEdCWc6XgGq_fc032471 ## test token
connections: null
dashboard_settings:
    ignore_filters: true
watched:
    - General
watched_folders_override: []
organization_name: Main Org.
secure_location: ""
output_path: test/bug
password: ""
storage: ""
url: http://localhost:3000
user_name: ""
user: null

gdg backup dashboards download

┌───────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ TYPE      │ FILENAME                                                                                          │
├───────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤
│ dashboard │ test/bug/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json                   │
│ dashboard │ test/bug/org_main-org/dashboards/Monthly+Incidents/bandwidth-dashboard.json                       │
│ dashboard │ test/bug/org_main-org/dashboards/Monthly+Incidents/bandwidth-patterns.json                        │
│ dashboard │ test/bug/org_main-org/dashboards/General/individual-flows-per-country.json                        │
│ dashboard │ test/bug/org_main-org/dashboards/Monthly+Incidents/individual-flows.json                          │
│ dashboard │ test/bug/org_main-org/dashboards/General/loss-patterns.json                                       │
│ dashboard │ test/bug/org_main-org/dashboards/General/other-flow-stats.json                                    │
│ dashboard │ test/bug/org_main-org/dashboards/General/science-discipline-patterns.json                         │
│ dashboard │ test/bug/org_main-org/dashboards/General/top-talkers-over-time.json                               │
│ dashboard │ test/bug/org_main-org/dashboards/Ignored/latency-patterns.json                                    │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-circuits.json                   │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-projects.json                   │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/dashboard-makeover-challenge.json │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/flow-analysis.json                │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-country.json                           │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-organization.json                      │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flow-information.json                                │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flows-by-science-discipline.json                     │
└───────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘

Okay, the name is: Monthly+Incidents which is correct.

repeating just in case it's being odd, same behavior.

test/bug/
test/bug/org_main-org
test/bug/org_main-org/dashboards
test/bug/org_main-org/dashboards/ES+net
test/bug/org_main-org/dashboards/ES+net/LHC+Data+Challenge
test/bug/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json
test/bug/org_main-org/dashboards/Monthly+Incidents
test/bug/org_main-org/dashboards/Monthly+Incidents/bandwidth-dashboard.json
test/bug/org_main-org/dashboards/Monthly+Incidents/bandwidth-patterns.json
test/bug/org_main-org/dashboards/Monthly+Incidents/individual-flows.json
test/bug/org_main-org/dashboards/General
test/bug/org_main-org/dashboards/General/individual-flows-per-country.json
test/bug/org_main-org/dashboards/General/loss-patterns.json
test/bug/org_main-org/dashboards/General/other-flow-stats.json
test/bug/org_main-org/dashboards/General/science-discipline-patterns.json
test/bug/org_main-org/dashboards/General/top-talkers-over-time.json
test/bug/org_main-org/dashboards/Ignored
test/bug/org_main-org/dashboards/Ignored/latency-patterns.json
test/bug/org_main-org/dashboards/linux%2Fgnu
test/bug/org_main-org/dashboards/linux%2Fgnu/Others
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-circuits.json
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-projects.json
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/dashboard-makeover-challenge.json
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/flow-analysis.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-country.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-organization.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flow-information.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flows-by-science-discipline.json

So far so good.

I still think you're missing a few step to help debug this. Unless I'm misreading this.

you're basically creating dashboards in your grafana-sync instance, using gdg so set context and pull all of them down, then create i git commit.

As far as I can tell the only GDG commands you're running are:

gdg tools ctx set grafana-sync
gdg tools ctx list
gdg backup dashboard download

All of that seems to be working fine.

I even tried to put "Monthly Report" in a different folder to make it nested with the same behavior:

┌───────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ TYPE      │ FILENAME                                                                                          │
├───────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤
│ dashboard │ test/bug/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json                   │
│ dashboard │ test/bug/org_main-org/dashboards/General/individual-flows-per-country.json                        │
│ dashboard │ test/bug/org_main-org/dashboards/General/loss-patterns.json                                       │
│ dashboard │ test/bug/org_main-org/dashboards/General/other-flow-stats.json                                    │
│ dashboard │ test/bug/org_main-org/dashboards/General/samir.json                                               │
│ dashboard │ test/bug/org_main-org/dashboards/General/science-discipline-patterns.json                         │
│ dashboard │ test/bug/org_main-org/dashboards/General/top-talkers-over-time.json                               │
│ dashboard │ test/bug/org_main-org/dashboards/Ignored/latency-patterns.json                                    │
│ dashboard │ test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents/bandwidth-dashboard.json           │
│ dashboard │ test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents/bandwidth-patterns.json            │
│ dashboard │ test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents/individual-flows.json              │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-circuits.json                   │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-projects.json                   │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/dashboard-makeover-challenge.json │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/flow-analysis.json                │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-country.json                           │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-organization.json                      │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flow-information.json                                │
│ dashboard │ test/bug/org_main-org/dashboards/linux%2Fgnu/flows-by-science-discipline.json                     │
└───────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘

and files:

find test/bug/
test/bug/
test/bug/org_main-org
test/bug/org_main-org/dashboards
test/bug/org_main-org/dashboards/ES+net
test/bug/org_main-org/dashboards/ES+net/LHC+Data+Challenge
test/bug/org_main-org/dashboards/ES+net/LHC+Data+Challenge/firefly-details.json
test/bug/org_main-org/dashboards/General
test/bug/org_main-org/dashboards/General/individual-flows-per-country.json
test/bug/org_main-org/dashboards/General/loss-patterns.json
test/bug/org_main-org/dashboards/General/other-flow-stats.json
test/bug/org_main-org/dashboards/General/samir.json
test/bug/org_main-org/dashboards/General/science-discipline-patterns.json
test/bug/org_main-org/dashboards/General/top-talkers-over-time.json
test/bug/org_main-org/dashboards/Ignored
test/bug/org_main-org/dashboards/Ignored/latency-patterns.json
test/bug/org_main-org/dashboards/Testing+Bug
test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents
test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents/bandwidth-dashboard.json
test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents/bandwidth-patterns.json
test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents/individual-flows.json
test/bug/org_main-org/dashboards/linux%2Fgnu
test/bug/org_main-org/dashboards/linux%2Fgnu/Others
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-circuits.json
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/flow-data-for-projects.json
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/dashboard-makeover-challenge.json
test/bug/org_main-org/dashboards/linux%2Fgnu/Others/n%2B_%3D23r/flow-analysis.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-country.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flow-data-per-organization.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flow-information.json
test/bug/org_main-org/dashboards/linux%2Fgnu/flows-by-science-discipline.json

The output all seems to be working an expected is valid and is repeatable. Everytime I run download it re-create the same file. No extra encoding or anything of the sort. You may have a bug elsewhere. Maybe something in how you're creating the MR with the data via bitbucket API?

test/bug/org_main-org/dashboards/Testing+Bug/Monthly+Incidents/bandwidth-dashboard.json

[safaci2000]

Can you also make sure that whatever you have on your local file system after download actually matches the git PR? @techuser12345

[safaci2000]

Moving this to conversation. as I'm leaning towards in issue with the encoding of your request to the bitbucket API.

[safaci2000]

@techuser12345 if you figure anything out let me know, but on my part I'm not able to reproduce any issue on any OS so I there's nothing else to do on my side.