Describe every usage metric and simple metric feature area by labkey-jeckels · Pull Request #8228 · LabKey/platform

labkey-jeckels · 2026-10-23T22:47:24Z

Rationale

Documents what every usage metric reports to mothership, so each value can be understood without reading the code that produces it.

The provider API changes, so the other fb_metric_descriptions PRs must merge with this one.

GH Issue 1775

Related Pull Requests

Changes

Every usage metrics provider reports a description with each value; the separate described-provider interface is merged into the base one.
Metrics reported only on some servers can be described without being reported.
Simple metric feature areas have fixed names and descriptions, including the client-side areas counted by @labkey/components.
Descriptions for the metrics of platform modules.

Every usage metrics provider now reports a description with each value, and simple metric feature areas get descriptions too, including the client-side areas counted by @labkey/components.

…ions

labkey-adam · 2026-10-26T15:10:01Z

This is from the previous change, but since this catch is per-provider, shouldn't the logging highlight the provider that failed?

Also, I guess this was intentional, but unfortunate that we have to generate all the metrics just to get the descriptions.

Also, I guess this was intentional, but unfortunate that we have to generate all the metrics just to get the descriptions.

Claude kept lamenting on that during its reviews. It didn't seem worth the complexity of decoupling them (and potential drift) since the descriptions will only need to be collected occasionally and every server already recomputes its metric values daily anyway.

It would be easy enough to capture and stash the descriptions during the metric submission process but I wasn't going to bother to automate export/import of them yet.

This is from the previous change, but since this catch is per-provider, shouldn't the logging highlight the provider that failed?

The stack trace should contain the class name of the provider. That's often a lambda. I don't know if it's worth a pass to include a name for every provider at registration time.

Also, I guess this was intentional, but unfortunate that we have to generate all the metrics just to get the descriptions.

Claude kept lamenting on that during its reviews. It didn't seem worth the complexity of decoupling them (and potential drift) since the descriptions will only need to be collected occasionally and every server already recomputes its metric values daily anyway.

It would be easy enough to capture and stash the descriptions during the metric submission process but I wasn't going to bother to automate export/import of them yet.

My thought: UsageMetrics.put() has the (for now) option of taking a Supplier<Object>. If a supplier is provided, the metrics enumerator will resolve it and the metrics description exporter will not. We can migrate to suppliers over time. Should be an easy change for Claude to implement.

This is from the previous change, but since this catch is per-provider, shouldn't the logging highlight the provider that failed?

The stack trace should contain the class name of the provider. That's often a lambda. I don't know if it's worth a pass to include a name for every provider at registration time.

Sure, the name is there. Maybe just update the message to say "a provider in module XXX failed..." since it's not the entire module that failed.

OK, updated.

labkey-adam · 2026-10-26T22:48:53Z

    }

+    /** Calls the supplier only when values are reported, so a {@code reportedIf(false)} view skips the work. A literal null value resolves here. */
+    public UsageMetrics put(@NotNull String key, @Nullable Supplier<?> value, @NotNull String description)


Oh good, so we're already accepting a Supplier

I converted more, but not all, callers to use a Supplier

labkey-adam · 2026-10-26T22:52:31Z

        return this;
    }

+    /** Calls the supplier only when values are reported, so a {@code reportedIf(false)} view skips the work. A literal null value resolves here. */


What's a view? Seems like an odd and overloaded term for us.

Updated the comment. It's just a render of the descriptions without grabbing the metrics.

labkey-adam · 2026-10-26T23:04:05Z

+import org.labkey.api.usageMetrics.SimpleMetricsService;
+
+/** Describes the client-side feature areas that @labkey/components counts */
+public final class ClientSideMetricDescriptions


Maybe I missed it, but I didn't see any place where we alert (e.g., log an error or warning, or throw) when we receive a client-side metric that isn't described.

I went back and forth on this.

I pushed an update that logs once per server startup when we get a client-side metric that's not linked to a description. In dev mode, it's ERROR to get caught by automated tests. In prod mode, it's WARN as we get spammed by bots sometimes that make up descriptions.

Also flag simple metric feature areas that lack a description and clarify describe-only terminology, per review feedback.

…ions

… done

## Rationale Describes the Flow and Protein usage metrics, using the API added in the platform PR. [GH Issue 1775](LabKey/internal-issues#1775) ## Related Pull Requests - LabKey/platform#8228 - LabKey/limsModules#2564 - LabKey/premiumModules#821 - LabKey/customModules#289 - LabKey/targetedms#1298 - LabKey/ehrModules#1232 ## Changes - Descriptions for Flow's and Protein's usage metrics.

## Rationale Describes the Specimen usage metrics, using the API added in the platform PR. [GH Issue 1775](LabKey/internal-issues#1775) ## Related Pull Requests - LabKey/platform#8228 - LabKey/limsModules#2564 - LabKey/premiumModules#821 - LabKey/commonAssays#1094 - LabKey/targetedms#1298 - LabKey/ehrModules#1232 ## Changes - Descriptions for Specimen's usage metrics.

## Rationale Describes the EHR usage metrics, using the API added in the platform PR. [GH Issue 1775](LabKey/internal-issues#1775) ## Related Pull Requests - LabKey/platform#8228 - LabKey/limsModules#2564 - LabKey/premiumModules#821 - LabKey/commonAssays#1094 - LabKey/customModules#289 - LabKey/targetedms#1298 ## Changes - Description for the participant history filter's client-side feature area.

## Rationale Describes the TargetedMS usage metrics, using the API added in the platform PR. [GH Issue 1775](LabKey/internal-issues#1775) ## Related Pull Requests - LabKey/platform#8228 - LabKey/limsModules#2564 - LabKey/premiumModules#821 - LabKey/commonAssays#1094 - LabKey/customModules#289 - LabKey/ehrModules#1232 ## Changes - Descriptions for TargetedMS's usage metrics.

Describe every usage metric and simple metric feature area

5a58ad4

Every usage metrics provider now reports a description with each value, and simple metric feature areas get descriptions too, including the client-side areas counted by @labkey/components.

labkey-jeckels added 3 commits October 23, 2026 18:09

Merge remote-tracking branch 'origin/develop' into fb_metric_descript…

ca02add

…ions

Claude review

1f5d687

Merge remote-tracking branch 'origin/develop' into fb_metric_descript…

9953542

…ions

labkey-jeckels requested a review from a team October 25, 2026 22:19

labkey-jeckels self-assigned this Oct 25, 2026

labkey-jeckels marked this pull request as ready for review October 25, 2026 22:19

labkey-adam reviewed Oct 26, 2026

View reviewed changes

labkey-adam self-requested a review October 26, 2026 22:14

labkey-adam approved these changes Oct 26, 2026

View reviewed changes

labkey-jeckels added 4 commits October 26, 2026 18:49

Skip usage metric queries when only collecting descriptions

2447133

Also flag simple metric feature areas that lack a description and clarify describe-only terminology, per review feedback.

Merge remote-tracking branch 'origin/develop' into fb_metric_descript…

4e898b1

…ions

Register more descriptions; defer logging until all registrations are…

456a159

… done

Claude review

a1908c2

labkey-jeckels merged commit f10b78e into develop Oct 28, 2026
10 of 12 checks passed

labkey-jeckels deleted the fb_metric_descriptions branch October 28, 2026 00:55

Conversation

labkey-jeckels commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rationale

Related Pull Requests

Changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

labkey-jeckels Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

labkey-jeckels commented Oct 23, 2026 •

edited

Loading

labkey-jeckels Oct 27, 2026 •

edited

Loading