Skip to main content
Question

Outcomes not being populated for certain queries

  • April 30, 2026
  • 2 replies
  • 47 views

gmkan
Forum|alt.badge.img

I have a real head-scratcher I’m struggling with on google scopes. I'm running queries via the "/legacy:legacyFetchUdmSearchView" API endpoint and seeing what looks like silent failure of "outcome" projections when filtering on a repeated field with "any".

This query returns events but each event has an empty "outcomes" field:

events:
metadata.log_type = "PAN_FIREWALL"
any principal.ip = "<source-ip>"

outcome:
$protocol = network.ip_protocol

The returned events have "network.ipProtocol" populated in the raw JSON (e.g. "ICMP"), so the field is present — it just isn't projecting through "outcome".

Rewriting with placeholder binding produces populated outcomes:

events:
metadata.log_type = "PAN_FIREWALL"
principal.ip = $ip
$ip = "<source-ip>"

outcome:
$protocol = network.ip_protocol

"$protocol" now comes back with "ICMP" as expected.

Strangely, the same "any" + scalar-projection pattern works fine when I filter on "target.ip" instead of "principal.ip" for similar PAN events:

events:
metadata.log_type = "PAN_FIREWALL"
any target.ip = "<destination-ip>"

outcome:
$protocol = network.ip_protocol

This returns events with "$protocol" populated. So whatever's going wrong with the "principal.ip" version isn't universal to "any" filtering.

Anybody have any idea what’s going on? Any help would be appreciated. 

2 replies

JeremyLand
Staff
Forum|alt.badge.img+7
  • Staff
  • May 6, 2026

That does seem unusual.

Do you get values in $protocol when running the initial query without the ANY?

events:
metadata.log_type = "PAN_FIREWALL"
principal.ip = "<source-ip>"

outcome:
$protocol = network.ip_protocol

Do you see the same behavior when you run the search in the UI?

The default behavior for is for search to return results if any of the repeated fields match,  there is a difference in behavior between the implicit ANY behavior vs when you explicitly call it but that should only require specifying ANY when you have multiple references to the same repeated field (or multiple fields inside repeated messages). Looking at the queries you shared they shouldn’t require specifying ANY.


gmkan
Forum|alt.badge.img
  • Author
  • New Member
  • May 13, 2026

Thanks for the response Jeremy. I ran your query without the ANY, and I still don’t get any outcome values. I’m only able to run this with the API - I don’t have access to the UI unfortunately. Any ideas on what’s causing the outcomes to not appear?