Call stack thread ids UI not refreshed with thread names after GDB command

Environment

• OS and version: Ubuntu 20.04/22.04, W10, W11. Applies to any version.
• VS Code: 1.83
• C/C++ extension: v1.17.5
• OS and version of remote machine (if applicable):
• GDB / LLDB version: Customized one.

Bug Summary and Steps to Reproduce

Bug Summary:

To debug a core dump from our target devices, we have two different data files regarding debug symbols and thread names.
Till now, all company has been using QtCreator for C++ development, but we're doing a transition to WSL2 + VSCode as the new setup. There is a modified version of GDB that has a function called map-thread-names, which as the name implies, it maps & loads the thread names dump file & associate it to the actual call stack from the Core Dump.

Well, this is done automatically with some configurations on QtCreator after you launch the Debugger: the call stack reflects accordingly the thread names. However, with VSCODE I'm able to use the customized GDB, launch the Core Dump and so on, even to run on the Debug Console the command map-thread-names and it will work but only in the Debug console context the thread IDs will be updated (map-thread-names && info threads). The Call Stack UI wont refresh or update anything after executing this command on the GDB Debug Console.

Before running map-thread-names:

After running function & show info threads. Updated on Debug Console but Call Stack UI still shows unmapped.

Debugger Configurations

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch Core Dump",
            "type": "cppdbg",
            "request": "launch",
            "program": "/mnt/disk1/app/bin/App",
            "args": ["-g "],
            "stopAtEntry": true,
            "coreDumpPath": "${workspaceFolder}/coreDump",
            "sourceFileMap": {
                "/shell": "${workspaceFolder}",
            },
            "targetArchitecture": "x64",
            "additionalSOLibSearchPath": "/mnt/disk1/app/lib",
            "cwd": "${fileDirname}",

            "miDebuggerPath":"/customgdb",
            "MIMode": "gdb",
            
            "logging": {
                "trace": true,
                "exceptions": true,
                "engineLogging":"verbose"
            }
        }
    ],
    "compounds": []
}

Debugger Logs

I would need to remove info, but can share if needed. I dont think it's relevant for this issue, however.

Other Extensions

No response

Additional Information

Shouldn't the Call Stack UI listen this & update/refresh? Is there anything that we can do to trigger a refresh in the UI to load them? If not, how difficult should be to implement an option like that for the extension?

Thanks!

Start by reproducing the core-dump session with the customized GDB, then compare the Debug Console output from map-thread-names <file> and info threads with the Call Stack UI. Investigate the extension's thread and call-stack refresh path; done means the UI reflects the updated thread names after the command, with a verified reproduction or regression test.