NotificationTriggerTranslator: Sequence contains more than one matching element

[paulkva]

Describe the bug
Upgraded to 0.9.13 (dev build) to try a new enhancement to the WatchLogs() method. That worked, but it turns out it breaks some of our other logic for handling triggers. Same problem with 0.9.12.

Steps to reproduce
Put the relevant code from your application that caused the issue to happen in the code block below

var triggers = this.Client.GetNotificationTriggers(prtgObject.Id).Where(t => t.Type == TriggerType.State).ToList();

What is the output of Get-PrtgClient -Diagnostic?

N/A?

Additional context
The object in question has two Down state triggers plus another inherited one. More importantly, it seems, the name of the NotificationAction for one of the triggers exists twice in PRTG's master list of NotificationActions.

Having two NotificationActions with the same exact name appears to be the result of a bug in our code, and the silver lining here is that this PrtgAPI bug helped us catch our bug. We're fixing our code to stop creating duplicates, so I don't consider the PrtgAPI bug to be high priority.

[lordmilko]

Hi @paulkva,

I don't understand what the bug is exactly. Are you saying PRTG exhibits some incorrect behavior when two notification actions have the same name, or is the bug something else? I see the error message in the title, so I guess that's it. In addition, you said that PrtgAPI 0.9.13-pre breaks something, but that the issue also exists in PrtgAPI 0.9.12 (meaning it wasn't caused by changes in PrtgAPI 0.9.13?)

[lordmilko]

In addition to the above, I just tried creating a second notification action called Ticket Notification and that doesn't appear to have caused any issues. Are you able to provide a stack trace?

[paulkva]

Ah yes, sorry for the lack of stack trace, and sorry it wasn't clear that PrtgAPI was throwing an exception. Here's the stack trace:

System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException: Sequence contains more than one matching element
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at PrtgAPI.Request.NotificationTriggerTranslator.TranslatePropertyFromCache(PropertyCache property, List`1 inheritedTriggers, TriggerPropertyEntry entry)
   at PrtgAPI.Request.NotificationTriggerTranslator.TranslatePropertyFromRawOrCache(PropertyCache property, Tuple`2[] zipped, TriggerPropertyEntry entry)
   at PrtgAPI.Request.NotificationTriggerTranslator.TranslateProperties(Tuple`2[] zipped)
   at PrtgAPI.Request.NotificationTriggerTranslator.TranslateTriggers(NotificationTriggerDataTrigger[] raw, Int32& parentId)
   at PrtgAPI.PrtgClient.GetNotificationTriggersInternal(Either`2 objectOrId, CancellationToken token)
   at PrtgAPI.PrtgClient.GetNotificationTriggers(Either`2 objectOrId)
   at (my code)...

I ran locally in debug mode (with 0.9.13-pre) and found the exception was thrown at NotificationTriggerTranslator.cs:line 195.

I believe these are the specific steps to re-create:

1. Create two NotificationActions with the exact same name as each other, and make sure the account running PrtgAPI has full access to both.
2. Assign one of those NotificationActions to a NotificationTrigger on any PrtgObject.
3. Call PrtgClient.GetNotificationTriggers and pass in the PrtgObject from step 2 (or its ID).

For what it's worth, we did steps 1 and 2 a long time ago with earlier versions of our code (and earlier versions of PrtgAPI), but it doesn't matter -- you could even do them manually on PRTG's front-end.

I'm guessing when you created a second Ticket Notification action, it didn't throw an error because by default, nobody has any access rights to the Ticket Notification action that PRTG provides by default. Maybe try granting full access to both for whichever account you use to login via PrtgAPI?

[lordmilko]

Hi @paulkva,

What is the display language you are using in PRTG? It sounds like it is not English

[lordmilko]

Hi @paulkva,

This issue should now be resolved. Please check out the latest pre-release build and let me know how you go

Out of interest, I see you mentioned you compiled PrtgAPI yourself to get more information from a debug build. Did you have any issues getting PrtgAPI to compile, and which method of compilation did you use? I find a lot of projects on the internet are an absolute nightmare to compile for some inexplicable reason, so one of my goals is to make compiling PrtgAPI "just work" as much as possible.

[paulkva]

Thanks for the resolution. For what it's worth, I am indeed using English. The main reason I compiled 0.9.13-pre myself was that I wanted it as a .nupkg file to minimize changes to my project's structure.

When I previously compiled 0.9.13-pre, here's what I did:

• checked out commit ce5f
• opened PrtgAPI.sln in Visual Studio
• updated Version.cs to 0.9.13.0
• hit Ctrl+Shift+B to build
• ran nuget pack PrtgAPI.csproj -Version 0.9.13
• copied the generated .nupkg file to my local nuget repo
  After that, when I pulled the updated package into my project, it created a number of Request and Tree folders containing several generated files and caused my build to fail, but deleting those new folders seemed to have fixed it.

After pulling the latest code, building PrtgAPI.sln in Visual Studio fails:

Request\PrtgClient.Generated.cs(1070,75): error CS0246: The type or namespace name 'AddSensorFailedParameters' could not be found (are you missing a using directive or an assembly referen
ce?) [C:\dev\PrtgAPI\src\PrtgAPI\PrtgAPI.csproj]
Request\PrtgClient.Generated.cs(1085,86): error CS0246: The type or namespace name 'AddSensorFailedParameters' could not be found (are you missing a using directive or an assembly referen
ce?) [C:\dev\PrtgAPI\src\PrtgAPI\PrtgAPI.csproj]

Building PrtgAPIv17.sln succeeds, but then nuget pack fails:

Error NU5012: Unable to find 'bin\Debug\PrtgAPI\bin\Debug\'. Make sure the project has been built.

I haven't had a chance to try the latest binary yet but can probably do so in the next few hours.

[paulkva]

I can confirm that including the latest binary as a direct reference fixes the exception that prompted me to open this issue. Thanks again! Happy to continue iterating on building locally if you'd like.

[lordmilko]

Thanks @paulkva!

I see I forgot to include the reference to AddSensorFailedParameters.cs in PrtgAPI.csproj as part of #140

I had a look at the issues with nuget pack you are described, and I am not surprised: by default nuget thinks it is appropriate to include all sorts of inappropriate files, including XML, text files and T4 Templates. You can see that the New-PrtgPackage cmdlet (accessible via build.cmd in the project root) specifies a lot more parameters when it tries to pack to work around this unavoidable behavior

PrtgAPI/build/CI/CI/New-CSharpPackage.ps1

Lines 50 to 63 in de6fb2c

	$nugetArgs = @(
	"pack"
	Join-Path $BuildFolder "src\PrtgAPI\PrtgAPI.csproj"
	"-Exclude"
	"**/*.tt;**/Resources/*.txt;*PrtgClient.Methods.xml;**/*.json"
	"-outputdirectory"
	"$OutputFolder"
	"-NoPackageAnalysis"
	"-symbols"
	"-version"
	$Version
	"-properties"
	"Configuration=$Configuration"
	)