1f27d7ef-045c-4b13-be21-3a6fa9a7e5a6

Committed 11 Apr 2025 10:13PM CUT coverage: 85.212% (+0.01%) from 85.201%

Build # 1f27d7ef-045c-4b13-be21-3a6fa9a7e5a6

Build Type

Pull #5500

circleci

Committed by

groovecoder

Commit Message

MPP-4012 - feat(glean): log API access as Glean server event

Introduce a new `api.accessed` Glean event to capture accesses to Relay API
endpoints. This includes the HTTP method and endpoint path, and logs events
for all `/api/` prefixed routes via a new middleware component.

- Added `record_api_accessed()` to `EventsServerEventLogger`
- Extended `RelayGleanLogger` with `log_api_accessed()` for easier integration
- Registered `GleanApiAccessMiddleware` to log access for all API routes
- Added corresponding unit test for API access logging
- Updated `relay-server-metrics.yaml` to define the `api.accessed` metric
- Updated notification email for several existing metrics to use relay-team@mozilla.com

Pull Request Pull Request #5500: WIP: MPP-4012 - feat(glean): log API access as Glean server event

Run Details

2461 of 3597 branches covered (68.42%)

Branch coverage included in aggregate %.

38 of 39 new or added lines in 5 files covered. (97.44%)

1 existing line in 1 file now uncovered.

17258 of 19544 relevant lines covered (88.3%)

9.83 hits per line

Source File
Press 'n' to go to next uncovered line, 'b' for previous

0.0

/frontend/src/components/Localized.tsx

// Imports of `Localized` from @fluent/react are forbidden because the component
// in this file should be used instead, but of course this component can use it
// just fine:
// eslint-disable-next-line no-restricted-imports
import { LocalizedProps, Localized as OriginalLocalized } from "@fluent/react";
import { cloneElement, isValidElement, useEffect, useState } from "react";
import { useL10n } from "../hooks/l10n";

/**
 * Wraps @fluent/react's Localized to be consistent between prerender and first render
 *
 * React will throw a tantrum if the HTML rendered during the build differs from
 * the DOM rendered by React when running client-side. However, at build-time we
 * don't yet know the user's locale. Thus, if we render strings in the user's
 * locale on the first client-side render, we'll make React unhappy, and who
 * wants that?
 *
 * To work around this, the useL10n hook makes sure that the English strings are
 * rendered when both prerendering and doing the first client-side render, and
 * only after that use the language that aligns with the user's preferences.
 * Thus, while pre-rendering and during the first client-side render, we call
 * out to that hook.
 *
 * This means tags embedded in the localised strings won't get added initially,
 * but since that's only for SEO and the initial render, that's acceptable.
 */
export const Localized = (props: LocalizedProps) => {
  const [isPrerendering, setIsPrerendering] = useState(true);
  const l10n = useL10n();

  useEffect(() => {
    setIsPrerendering(false);
  }, []);

  if (isPrerendering) {
    // `useL10n` makes sure that this is a prerenderable string
    return isValidElement(props.children) ? (
      cloneElement(
        props.children,
        {},
        <>{l10n.getString(props.id, props.vars)}</>,
      )
    ) : (
      <>{l10n.getString(props.id, props.vars)}</>
    );
  }

  return <OriginalLocalized {...props} />;
};

1	// Imports of `Localized` from @fluent/react are forbidden because the component
2	// in this file should be used instead, but of course this component can use it
3	// just fine:
4	// eslint-disable-next-line no-restricted-imports
5	import { LocalizedProps, Localized as OriginalLocalized } from "@fluent/react";	×
6	import { cloneElement, isValidElement, useEffect, useState } from "react";	×
7	import { useL10n } from "../hooks/l10n";	×
8
9	/**
10	* Wraps @fluent/react's Localized to be consistent between prerender and first render
11	*
12	* React will throw a tantrum if the HTML rendered during the build differs from
13	* the DOM rendered by React when running client-side. However, at build-time we
14	* don't yet know the user's locale. Thus, if we render strings in the user's
15	* locale on the first client-side render, we'll make React unhappy, and who
16	* wants that?
17	*
18	* To work around this, the useL10n hook makes sure that the English strings are
19	* rendered when both prerendering and doing the first client-side render, and
20	* only after that use the language that aligns with the user's preferences.
21	* Thus, while pre-rendering and during the first client-side render, we call
22	* out to that hook.
23	*
24	* This means tags embedded in the localised strings won't get added initially,
25	* but since that's only for SEO and the initial render, that's acceptable.
26	*/
27	export const Localized = (props: LocalizedProps) => {	×
28	const [isPrerendering, setIsPrerendering] = useState(true);	×
29	const l10n = useL10n();	×
30
31	useEffect(() => {	×
32	setIsPrerendering(false);	×
33	}, []);
34
35	if (isPrerendering) {	×
36	// `useL10n` makes sure that this is a prerenderable string
37	return isValidElement(props.children) ? (
38	cloneElement(	×
39	props.children,
40	{},
41	<>{l10n.getString(props.id, props.vars)}</>,
42	)
43	) : (
44	<>{l10n.getString(props.id, props.vars)}</>
45	);
46	}
47
48	return <OriginalLocalized {...props} />;
49	};

mozilla / fx-private-relay / 1f27d7ef-045c-4b13-be21-3a6fa9a7e5a6

Source File Press 'n' to go to next uncovered line, 'b' for previous

Source File
Press 'n' to go to next uncovered line, 'b' for previous