commit 2ffcfb5c9b10677834e89397a51f031e823bda16
author Vadim Shtayura <vadimsh@chromium.org> Tue Oct 29 23:57:26 2024
committer LUCI CQ <infra-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Oct 29 23:57:26 2024
tree 4a4bd53f51b5fbd351699f500900730ac32c4e4a
parent 4827eb2dcf4f403b6dd054865a4a8c2201e9f1af

[prpc] Add a test that covers existing field mask semantics.

This will be used to make sure we don't regress existing
fragile state of things during the refactoring.

The existing fragile state of things:
1. Without HackFixFieldMasksForJSON set field masks are
   supported only using {"path":[...]} syntax, but they
   still can include "advanced" masks like `a.*.b`.
2. With HackFixFieldMasksForJSON set field masks are supported
   using both object and string syntax and they can include
   "advanced" masks.

The goal of the refactoring would be to replace
HackFixFieldMasksForJSON with HackSupportForAdvancedFieldMasks
(or something like that), with following properties:

1. Without HackSupportForAdvancedFieldMasks set field masks
   are supported using object or string syntax, but they can't
   be "advanced" (not because we explicitly want to forbid this,
   but because protobuf v2 doesn't support them). In this mode
   no hacks are happening, we just use standard protobuf APIs.
2. Setting HackSupportForAdvancedFieldMasks will be equivalent
   to setting HackFixFieldMasksForJSON right now.

Then all current servers that set HackFixFieldMasksForJSON, but
don't actually support advanced field masks, will stop using
any hacks.

Few services that still need "advanced" field masks will keep using
the hack until their API is refactored to avoid using advanced field
masks.

R=iannucci@chromium.org, gregorynisbet@google.com
BUG=b/376137855

Change-Id: I863f03194e24bc47a5022f22b3685b5f77d9782f
Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5976922
Reviewed-by: Gregory Nisbet <gregorynisbet@google.com>
Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>