You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we ingest the chromium enums from the Chromium Code Base, we keep a list of the features (while skipping DRAFT and OBSOLETE features). Then we proceed to store them. But before we store them, we use the conversion logic to convert the enum key to a web feature id. If it does match, we store a mapping of the enum ID PK to the Web feature PK for efficient joins. If it does not match, we log a warning:
Instead, we should have some better alerting around this. We should emit a metric or signal that something is wrong. This should let someone know that they need to fix something in the Chromium code base.
The text was updated successfully, but these errors were encountered:
cc: @DanielRyanSmith: This may be an easier alternative to the Presubmit directly in Chromium. Of course, it would be great to have the Presubmit but if a web feature ID ever changes, it could break the Chromium CI build.
Here's an idea I suggested while talking to @past
Background
When we ingest the chromium enums from the Chromium Code Base, we keep a list of the features (while skipping DRAFT and OBSOLETE features). Then we proceed to store them. But before we store them, we use the conversion logic to convert the enum key to a web feature id. If it does match, we store a mapping of the enum ID PK to the Web feature PK for efficient joins. If it does not match, we log a warning:
webstatus.dev/lib/gcpspanner/spanneradapters/chromium_historgram_enum_consumer.go
Lines 66 to 77 in c7946b1
Instead, we should have some better alerting around this. We should emit a metric or signal that something is wrong. This should let someone know that they need to fix something in the Chromium code base.
The text was updated successfully, but these errors were encountered: