Al: Rule214BlindWriteLocalRecord exception with rule AA0214

[hougaard]

Name: AL Language
Id: ms-dynamics-smb.al
Description: AL development tools for Dynamics 365 Business Central
Version: 5.0.235548
Publisher: Microsoft

Analyzer 'Microsoft.Dynamics.Nav.CodeCop.Design.Rule214BlindWriteLocalRecord' threw an exception of type 'System.InvalidCastException' with message 'System.InvalidCastException: Unable to cast object of type 'Microsoft.Dynamics.Nav.CodeAnalysis.BoundFieldAccess' to type 'Microsoft.Dynamics.Nav.CodeAnalysis.IInvocationExpression'.
at Microsoft.Dynamics.Nav.CodeCop.Design.Rule214BlindWriteLocalRecord.ProcessingInvocation(SyntaxNode syntaxNode, PooledDictionary2 processInvocations, SyntaxNodeAnalysisContext syntaxNodeAnalysisContext) at Microsoft.Dynamics.Nav.CodeCop.Design.Rule214BlindWriteLocalRecord.<>c.<Analyze>b__5_0(SyntaxNodeAnalysisContext syntaxNodeAnalysisContext) in D:\a\1\s\source\Prod\Microsoft.Dynamics.Nav.CodeCop\Design\Rule214BlindWriteLocalRecord.cs:line 46 at Microsoft.Dynamics.Nav.CodeAnalysis.Diagnostics.AnalyzerExecutor.<>c__DisplayClass52_1.<ExecuteSyntaxNodeAction>b__1() in D:\a\1\s\source\Prod\Microsoft.Dynamics.Nav.CodeAnalysis\DiagnosticAnalyzer\AnalyzerExecutor.cs:line 742 at Microsoft.Dynamics.Nav.CodeAnalysis.Diagnostics.AnalyzerExecutor.ExecuteAndCatchIfThrows_NoLock(DiagnosticAnalyzer analyzer, Action analyze, Nullable1 info) in D:\a\1\s\source\Prod\Microsoft.Dynamics.Nav.CodeAnalysis\DiagnosticAnalyzer\AnalyzerExecutor.cs:line 1079'

[NKarolak]

The error still exists with AL Language 5.0.236243 (latest available version).
It is thrown for the app.json a hundred times (not kidding), as soon as CodeCop is activated.

VS Code Problems output (1 of 100):

app.json    AD0001  Analyzer 'Microsoft.Dynamics.Nav.CodeCop.Design.Rule214BlindWriteLocalRecord' threw an exception of type 'System.InvalidCastException' with message 'System.InvalidCastException: Unable to cast object of type 'Microsoft.Dynamics.Nav.CodeAnalysis.BoundFieldAccess' to type 'Microsoft.Dynamics.Nav.CodeAnalysis.IInvocationExpression'.
   at Microsoft.Dynamics.Nav.CodeCop.Design.Rule214BlindWriteLocalRecord.ProcessingInvocation(SyntaxNode syntaxNode, PooledDictionary`2 processInvocations, SyntaxNodeAnalysisContext syntaxNodeAnalysisContext)        
   at Microsoft.Dynamics.Nav.CodeCop.Design.Rule214BlindWriteLocalRecord.<>c.<Analyze>b__5_0(SyntaxNodeAnalysisContext syntaxNodeAnalysisContext) in D:\a\1\s\source\Prod\Microsoft.Dynamics.Nav.CodeCop\Design\Rule214BlindWriteLocalRecord.cs:line 46     
   at Microsoft.Dynamics.Nav.CodeAnalysis.Diagnostics.AnalyzerExecutor.<>c__DisplayClass52_1.<ExecuteSyntaxNodeAction>b__1() in D:\a\1\s\source\Prod\Microsoft.Dynamics.Nav.CodeAnalysis\DiagnosticAnalyzer\AnalyzerExecutor.cs:line 742        
   at Microsoft.Dynamics.Nav.CodeAnalysis.Diagnostics.AnalyzerExecutor.ExecuteAndCatchIfThrows_NoLock(DiagnosticAnalyzer analyzer, Action analyze, Nullable`1 info) in D:\a\1\s\source\Prod\Microsoft.Dynamics.Nav.CodeAnalysis\DiagnosticAnalyzer\AnalyzerExecutor.cs:line 1099'   0   0

Edit: the error disappeared as soon as I activated the AppSource cop....?

[hougaard]

Still happens in build 5.0.249661

[BrianThorChristensen]

This seems to happen for me, when I refer to a field that has the words "get" or "find" in the name.
Like "Target" or "MessageType".
Steps to reproduce:

1. Create a codeunit.
2. Create a procedure with a customer variable and type: Message('%1', Customer."Budgeted Amount");
3. build the project and change to the problems pane

[StefanMaron]

Having the same issue... is it possible to deactivate the underling "Rule214".
I tried to add to my custom ruleset but with no success.

[kasperdj]

Any progress on this issue. Currently when there is a "runtime" error in the CodeCop Analyzer referencing app.json the CodeCop stops working and we will not see the error before our build pipeline fails. At the moment we have a lot over overhead due to this issue.

[atoader]

@MarcHansenMicrosoft can you provide an update?

[MarcHansenMicrosoft]

We have a bug on it but not gotten to it yet

[kasperdj]

I can provide an al project with the problem if you setup a private file transfer workspace and send this link to the workspace to [email protected]

[MarcHansenMicrosoft]

Not sure that I can do that due to you code rights.
Could you make it as a pull request on GitHub?
Or is it all of your codebase?

[kasperdj]

It's "my" codebase, so a PR is a no-go

[MarcHansenMicrosoft]

Can you trim it to app.json and a source file?

[kasperdj]

app.json is no problem, but I don't know which .al file that causes the CodeCop to crash!
As additional info, the CodeCop works in my DevOps pipeline - where there is no UI.

[MarcHansenMicrosoft]

@atoader could you have a look at what in the VSCode UI could be the reason for this?

[atoader]

@MarcHansenMicrosoft the stacktrace above indicates an invalid cast. It doesn't have anything to do with the UI. The exception is most likely swallowed in the CI/CD pipeline. @kasperdj can you run alc from the commandline while using the -log:"Path to log file.json" -loglevel:Warning arg to write the output to a file. I am curious if that captures it.

[kasperdj]

@MarcHansenMicrosoft here is the output of your request. It does not seam to reveal a lot of additional details.

DevOps Compile output with Analyzers enabled:

alc.exe called via DevOps will not crash even though the analyzer are in use!
See alc.exe call below from our DevOps step log:

C:\Run\Microsoft.al\al-4.0.176004\extension\bin\alc.exe /packagecachepath:"c:\Run\DevOps\PackageCache" /project:"c:\Run\DevOps\app" /out:"c:\Run\DevOps\Elbek & Vejrup A_S_MyAppNameHidden_1500.1.0.780_APP.app" /fullpaths /ruleset:"c:\Run\DevOps\app\custom.ruleset.json" /analyzer:"C:\Run\Microsoft.al\al-4.0.176004\extension\bin\Analyzers\Microsoft.Dynamics.Nav.CodeCop.dll","C:\Run\Microsoft.al\al-4.0.176004\extension\bin\Analyzers\Microsoft.Dynamics.Nav.UICop.dll","C:\Run\Microsoft.al\al-4.0.176004\extension\bin\Analyzers\Microsoft.Dynamics.Nav.AppSourceCop.dll" /assemblyprobingpaths:C:\Windows\assembly

[MarcHansenMicrosoft]

Thanks

We will investigate

[kevindstanley1988]

Having the same exact warning here while upgrade my codebase from 15 -> 16. Our app is very large, so I do not know which file is the cause. I checked my app.json and launch.json to make sure it matches up to what AL:GO produces

[salgiza]

Could you please disable this rule (by default) until it works? It's going to be great when it does something, but right now it constantly fails in all of our projects.

As an example, I just disabled our ruleset to check if it had finally been fixed in the version of the AL extension released this morning and I got 207 errors, in a single project. Half of them crashes from the analyzer, half of them pieces of code where no record is modified/saved, yet the analyzer complained that the record should be updated before writing to disk (!).

As a simple example of code that fails with this analyzer (this one does not crash):

local procedure GetNextPurchCommentLineNo(PurchHeader: Record "Purchase Header"): Integer
var
    PurchCommentLine: Record "Purch. Comment Line";
begin
    PurchCommentLine.SetRange("Document Type", PurchHeader."Document Type");
    PurchCommentLine.SetRange("No.", PurchHeader."No.");
    PurchCommentLine.SetRange("Document Line No.", 0);
    if PurchCommentLine.FindLast() then
        exit(PurchCommentLine."Line No." + 10000)
    else
        exit(10000);
end;

The previous code finds the last purchase line for a document, and returns its no + 10000 or 10000. It does not modify the line, it does no inserts, it just reads a single value. The result:

The record PurchCommentLine should be modified before saving to the database.AL(AA0214)

[Jeeve65]

In one project, I get this error if I add this one line of code:
MdmMasterChange.SetRange("Target Type", MdmMasterChange."Target Type"::Global);

where
MDMMasterChange is a record
"Target Type" is an option field defined as: Option undefined, Global, Subscription, Client

[salgiza]

@Jeeve65 I re-enabled the rule again on the project I mentioned yesterday, and I can confirm that all of the variables (that I've checked) where the analyzer threw a warning by mistake, had a SetRange or SetFilter done to them (not necessarily with an option/enum field).

I don't know whether that will be the only case in which it fails, but I'm sure that's what causes the high number of false warnings in some of our apps.

[kasperdj]

Any progress on fixing this issue?

I think the main root cause is missing backward compability as our DevOps uses a compiler version (VSIX) matching our target platform - and here the CodeCop works fine - but it's very late in the process to get the warnings and this is causing a lot of additional overhead on our projects!

[MarcHansenMicrosoft]

It is being worked on :-)

[MarcHansenMicrosoft]

fixed in master

[kasperdj]

Hi @MarcHansenMicrosoft

I can see that this issue should have been fixed based on you update late June.

However not all issues have been resolved as we can still "provoke" the CodeCop compiler runtime error in our projects and below is an example of this using the latest AL Language extension and working on a BC 15 OnPrem project:

So in my opinion, the issue still exists. I can share a private link to Microsoft with the customer project in which we have this issue - to ease your analysis.

Furtermore, if we activate the AppSourceCop in the same project, then the compiler bugs related to the CodeCop goes away - maybe it's a priority in the compiler:

[MarcHansenMicrosoft]

Hi @kasperdj,

Nice details, I like the twist about the AppSourceCop.

I quite sure we fixed the first issue.
Having issues the might crash the analyzer is a general problem and it will be to messy if we keep reopening the same github item.

Could I get you to create a new bug with your details?
please also add link to this item as well thanks.

/Marc

[kasperdj]

New issue created regarding my last post: https://github.com/microsoft/AL/issues/6116

[hougaard]

Still getting this: