Fallback to decompilation for go-to-def when sourcelink doesn't find metadata

[baronfel]

If you go to def on a library where we start our sourcelink probing, if we can't discover sourcelink documents we should fallback to the C# decompilation.

[github-actions]

🤖 This is an automated response from Repo Assist.

I traced the current code to understand where the fallback is (and isn't) happening.

In ParseAndCheckResults.fs, the go-to-definition handler covers three external-symbol cases:

Path	SourceLink tried?	Decompile fallback?
ExternalDecl with source range hint	✅ Yes	✅ Yes (line 227)
ExternalDecl with no range hint	❌ No	✅ Yes (line 228)
DeclFound pointing to a non-existent file	✅ Yes	❌ Missing

The gap is in the third path (around line 207):

| Error reason -> return ResultOrString.Error(sprintf "%A" reason)

When SourceLink lookup fails here, the code returns an error instead of attempting decompilation. The difficulty is that this path has the assembly file path and a NormalizedRepoPathSegment but not a FindDeclExternalSymbol, which is what Decompiler.tryFindExternalDeclaration requires. Obtaining one would require calling checkResults.GetSymbolUseAtLocation and then mapping the FSharpSymbol to a FindDeclExternalSymbol — which is doable but non-trivial.

A simpler interim improvement would be to add a needs-upstream-work comment or convert the Error return to attempt decompilation by re-extracting the symbol. Happy to help with an implementation sketch if a contributor wants to pick this up!

Generated by Repo Assist

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@828ac109efb43990f59475cbfce90ede5546586c. View source at https://github.com/githubnext/agentics/tree/828ac109efb43990f59475cbfce90ede5546586c/workflows/repo-assist.md.