bug: crashing when handling null-ls LSP results

[emmanueltouzery]

Neovim version (nvim -v)

0.8.3 release

Operating system/version

fedora 37

Output of :AerialInfo

Aerial Info

Filetype: typescript
Configured backends:
lsp (supported) (attached)
Show symbols: Class, Constructor, Enum, Function, Interface, Module, Method, Struct, Constant, Variable

Describe the bug

when loading aerial (telescope plugin) on typescript files, with only LSP as enabled, in my setup, I have two LSP servers: null-ls (to get indentation and linters) and the typescript LS. Naturally, null-ls is ready faster.
When null-ls handles the request, it breaks aerial's fetch_symbols_sync... bizarrely, it doesn't return {1 = ...} as aerial expects, but {2= ...}.

That means that aerial crashes, and more precisely with this stack:

E5108: Error executing lua ...acker/start/aerial.nvim/lua/aerial/backends/lsp/init.lua:50: attempt to index a nil value
stack traceback:
	...acker/start/aerial.nvim/lua/aerial/backends/lsp/init.lua:50: in function 'fetch_symbols_sync'
	...r/start/aerial.nvim/lua/telescope/_extensions/aerial.lua:36: in function 'aerial'
	[string ":lua"]:1: in main chunk

Either adding a guard (if lsp_results[1] ~= nil then..), or a clause taking into account specifically the 2 fix it:

-    callbacks.handle_symbols(lsp_results[1].result, bufnr)
+    if lsp_results[1] == nil then
+      callbacks.handle_symbols(lsp_results[2].result, bufnr)
+    else
+      callbacks.handle_symbols(lsp_results[1].result, bufnr)
+    end

The second solution is a little better, because that means that the request actually works. The first solution makes it at least not crash, and then it works when the user retries once the typescript LS finishes loading.
However I hesitate to make a PR with the "better " fix because.. it doesn't exactly feel right...

Steps To Reproduce

unfortunately making a config to reproduce this and setting up a typescript test program, and so on seems really overkill...

but generally speaking i blame null-ls when working with the typescript LS, which is relatively slow to start (that's another issue.. on a small typescript project, it would probably be fast enough to start that the issue wouldn't be reproducible).

Expected Behavior

at least aerial shouldn't crash in this situation, at best it could know how to interpret the response it gets, weird as it is.

Minimal example file

No response

Minimal init.lua

sorry :(

Additional context

No response

[stevearc]

This is actually just some bad handling of the LSP response. Should be fixed now.