Questions about CGRateS ConfigSv1 methods

52 views
Skip to first unread message

Salvinder Parhar

unread,
Mar 22, 2026, 4:02:16 PM (12 days ago) Mar 22
to cgr...@googlegroups.com
Hello team CGRateS,

Hope you are all doing well.

I've been playing with the ConfigSv1 methods to get/set/reload my runtime CGRateS configuration, and I'm not sure if I'm doing something wrong here, but below is what I've experienced and some of my questions about it, if you can please answer.

1/ I used the method "ConfigSv1.GetConfig" to get the current contents of the "cdrs" config object.

"ConfigSv1.GetConfig" method HTTP JSON-RPC request
{
    "method": "ConfigSv1.GetConfig",
    "params": [
        {
            "Tenant": null,
            "Section":"cdrs",
            "APIOpts": {}
        }
    ]
}

Response back
{
    "id": null,
    "result": {
        "cdrs": {
            "attributes_conns": [
                "*localhost"
            ],
            "chargers_conns": [
                "*localhost"
            ],
            "compress_stored_cost": true,
            "ees_conns": [
                "*localhost"
            ],
            "enabled": true,
            "extra_fields": [
                "~*req.variable_accountcode",
                "~*req.variable_call_direction"
            ],
            "online_cdr_exports": [
                "http_billing_event",
            ],
            "rals_conns": [
                "*internal"
            ],
            "scheduler_conns": [],
            "session_cost_retries": 5,
            "stats_conns": [],
            "store_cdrs": true,
            "thresholds_conns": []
        }
    },
    "error": null
}

Returned result shows that
"online_cdr_exports" is set with the value "http_billing_event".
And now if I wanted to remove this value 
"http_billing_event", I'd use method "ConfigSv1.SetConfig" to set "online_cdr_exports" to an empty list like below:
{
    "method": "ConfigSv1.SetConfig",
    "params": [
        {
"Tenant": null,
            "DryRun": false,
            "Config": {
                "cdrs": {
                    "online_cdr_exports": []
                }
            }
        }
    ]
}

I get a success response back saying:
{
    "id": null,
    "result": "OK",
    "error": null
}
 
But "online_cdr_exports" is still set to "http_billing_event" in the "cdrs" config object if I query it using the "ConfigSv1.GetConfig" again. This same approach works just fine if I try to remove/empty out any other list type values of any other key attributes (like "attributes_conns", "chargers_conns", "ees_conns", "extra_fields", "rals_conns") in the "cdrs" config object, just not when I try it with "online_cdr_exports".

2/ If I use method "ConfigSv1.SetConfig" to set "online_cdr_exports" with a value that is not a valid exporter ID in my system, it complains about it but somehow still set those invalid values for "online_cdr_exports".
{
    "method": "ConfigSv1.SetConfig",
    "params": [
        {
            "Tenant": null,
            "DryRun": false,
            "Config": {
                "cdrs": {
                    "online_cdr_exports": ["test", "fake_ees_id", ""]
                }
            }
        }
    ]
}

{
    "id": null,
    "result": null,
    "error": "<CDRs> cannot find exporter with ID: <test>"
}

Retrieving "cdrs" config after setting "online_cdr_exports" with invalid values above shows that despite complaining about the invalid ID it still ended up setting those IDs, even an empty string. And at this point I don't even have a way to remove these invalid ID's without restarting my CGRateS service.
{
    "method": "ConfigSv1.GetConfig",
    "params": [
        {
            "Tenant": null,
            "Section":"cdrs",
            "APIOpts": {}
        }
    ]
}

Response back:
{
    "id": null,
    "result": {
        "cdrs": {
            "attributes_conns": [
                "*localhost"
            ],
            "chargers_conns": [
                "*localhost"
            ],
            "compress_stored_cost": false,
            "ees_conns": [
                "*localhost"
            ],
            "enabled": true,
            "extra_fields": [
                "~*req.variable_accountcode",
                "~*req.variable_call_direction"
            ],
            "online_cdr_exports": [
                "http_billing_event",
                "test",
                "fake_ees_id",
                ""
            ],
            "rals_conns": [
                "*internal"
            ],
            "scheduler_conns": [],
            "session_cost_retries": 5,
            "stats_conns": [],
            "store_cdrs": true,
            "thresholds_conns": []
        }
    },
    "error": null
}

3/ All ConfigSv1 methods (ConfigSv1.GetConfig, ConfigSv1.SetConfig, ConfigSv1.ReloadConfig, ConfigSv1.GetConfigAsJSON, ConfigSv1.SetConfigFromJSON) use 'Tenant' and 'APIOpts' as key attributes in their request payloads. Is there a use case for these key attributes as well somewhere?

4/ If I update and reload the runtime CGRateS config using methods 'ConfigSv1.SetConfig' and 'ConfigSv1.ReloadConfig', these changes get overridden when I restart my CGRateS service next. Is there a way to persist these changes during service restart?

Thanks,
Sal

Armir Veliaj

unread,
Mar 24, 2026, 12:33:07 PM (10 days ago) Mar 24
to CGRateS
Hi Sal,

Regarding your first two issues, please open a separate GitHub issue for each on the CGRateS repository and we will follow up there once a fix is applied.

For your third question, Tenant and APIOpts are relevant only if you plan to use DispatcherS.

And for your fourth inquiry, this is by design in the v0.11 branch where changes made via ConfigSv1.SetConfig or ConfigSv1.ReloadConfig are applied in-memory only and do not persist after a service restart.
This is only supported in 1.0 branch, where config changes made via the API are saved and persist across restarts.

Hope this helps!
Thanks,
Armir

Salvinder Parhar

unread,
Mar 24, 2026, 2:38:14 PM (10 days ago) Mar 24
to CGRateS
Thanks Armir. As requested, I've opened the two separate GitHub issues, 5088 and 5090.

I really want to start looking into 1.0 branch, just waiting on some documentation to be available around how everything has been consolidated from having multiple csv's (for destinations, rates, destinationrates, ratingplans, ratingprofiles) into just one rates.csv.

Thanks,
Sal
Reply all
Reply to author
Forward
0 new messages