isAlarmActiveFiltered() not detecting shelved alarms

(Version 8.0.13)

I’m trying to use alarm-based visibility animations to show different symbols when different priority alarms are active or shelved. I configured two alarms on a single tag for ease of testing. I use coalesce() with isAlarmActiveFiltered() to tell me the highest priority that’s active. See my expression below:

coalesce(
	// Check active High/Critical alarms (priority 3-4)
	// Return 5
	if(
		isAlarmActiveFiltered("*","*","*",3,4,0,1,0),
		5,
		null
	),
	
	// Check active Medium alarms (priority 2)
	// Return 4
	if(
		isAlarmActiveFiltered("*","*","*",2,2,0,1,0),
		4,
		null
	),
	
	// Check active Low alarms (priority 1)
	// Return 3
	if(
		isAlarmActiveFiltered("*","*","*",1,1,0,1,0), 
		3,
		null
	),

	// Check active Diagnostic alarms (priority 0)
	// Return 2
	if(
		isAlarmActiveFiltered("*","*","*",0,0,0,1,0),
		2,
		null
	),
	
	// Check active Shelved alarms (any priority 0-4)
	// Return 1
	if(
		isAlarmActiveFiltered("*","*","*",0,4,0,1,1),
		1,
		null
	),
	
	// No alarms active or shelved.
	// Return 0
	0
)

Note that in practice, the first wildcard of isAlarmActiveFiltered() (tagPath) will be replaced with ‘[tagProvider]tag/Path’.

My problem is that shelved alarms don’t get detected by the last isAlarmActiveFiltered(). When I shelve all active alarms, the expression outputs 0 instead of 1. I’ve also tried using that last instance as a standalone expression and it will return 1 when an alarm is active and unshelved, and 0 when it is shelved or cleared. I would expect 1 when active or shelved, and 0 when cleared.

Am I using the function incorrectly, is it not meant to do this, or is this a bug?

Thanks in advance.

Update - I’ve been in touch with support and they confirmed this is a bug, not user error. A bug ticket has been created, but there is no ETA the fix.

I’ve also learned that my use of this function in the client scope is poor form and could cause hangups:

No, not the use in client scope. The use on the foreground thread (which is where runScript bindings execute).

Nevermind. That’s the expression function, which can only be run in a binding. So yes, anything other than gateway/perspective scope is trouble.