Handle missing scopes

[igorlfs]

Hello!

I'm constantly running into the following error when navigating the call stack:

Error executing vim.schedule lua callback: ...nvim-dap/lua/dap/session.lua:846: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
	[C]: in function 'ipairs'
	...nvim-dap/lua/dap/session.lua:846: in function 'callback'
	...nvim-dap/lua/dap/session.lua:1093: in function <...nvim-dap/lua/dap/session.lua:1090>

Originally, I was navigating the call stack using session:_frame_set(frame), but I can reproduce the same issue when using require"dap".up()/down()

According to the spec, I don't think this parameter should be missing (since it's not optional), but I wonder if there's something else going on due to the navigation in the call stack?

I'm running into this issue with the vscode-js-debug specifically. What make the situation odd is that it looks like it always returns the scopes (but I haven't delved deep into that).

I can try crafting a minimal reproduction if necessary, or getting the traces. Let me know how to best handle the situation ^^

EDIT: related?

[mfussenegger]

Can you turn on logging and see if the debug adapter responds without providing the scopes? If so this needs an upstream bug report.

I'm not going to add workarounds for adapters that return responses which are invalid according to the spec.

[igorlfs]

Can you turn on logging and see if the debug adapter responds without providing the scopes?

I have enabled the logs, and it looks like the adapter does not respond with the scopes, but the response actually contains an error:

[DEBUG] 2025-03-16 18:16:02 dap/session.lua:1872	"request"	{
  arguments = {
    frameId = 244
  },
  command = "scopes",
  seq = 25,
  type = "request"
}
[DEBUG] 2025-03-16 18:16:02 dap/session.lua:1068	2	{
  body = {
    error = {
      format = "Variables not available in async stacks",
      id = 9234,
      showUser = false
    }
  },
  command = "scopes",
  request_seq = 25,
  seq = 2562,
  success = false,
  type = "response"
}

I'm not very familiar with the protocol, should this error be handled by the client, or is the adapter still at fault here?

[mfussenegger]

Can you try with #1475 ?

Looks like the problem was that the body of the error response was also set as response to the request handler.

[igorlfs]

Can you try with 1475?

Fixed, thanks!