@oneuptime/common 13.0.7 → 14.0.0

package/UI/Components/Graphs/DayUptimeGraph.tsx

@@ -39,10 +39,52 @@ export interface UptimeBarDaySummary {
   incidents: Array<UptimeBarTooltipIncident>;
 }
 
+/*
+ * One day's reading, measured server-side.
+ *
+ * The bars used to be derived purely from the timeline rows the browser
+ * happened to receive, and those rows arrive under a cap that silently drops
+ * history (see MonitorStatusTimelineService.getDailyUptimeAggregate). A day
+ * whose rows were dropped is indistinguishable, client-side, from a day that
+ * was genuinely quiet - so the graph painted both as the status page's
+ * `defaultBarColor`, which is GREEN on the overwhelming majority of pages.
+ * The page then asserted uptime for periods it had no data for.
+ *
+ * A reading carries how much of the day was actually COVERED by data, which
+ * is the thing the browser cannot infer for itself.
+ */
+export interface DayReading {
+  dayStart: Date;
+  daySeconds: number;
+  /* Zero means nothing was ever recorded for this day. */
+  coveredSeconds: number;
+  statusDurations: Array<StatusDuration>;
+}
+
+/*
+ * A day nobody measured is not a colour the operator gets to choose.
+ *
+ * `defaultBarColor` is branding for an ordinary good day; letting it also
+ * stand for "we have no idea" is exactly the conflation that made a page with
+ * a green default claim uptime it never recorded, and a page with a grey
+ * default look unmonitored while it was passing every check. This is a fixed
+ * neutral, drawn with a hatch so it is still distinguishable in greyscale and
+ * to a colour-blind reader.
+ */
+export const NO_DATA_BAR_COLOR: Color = new Color("#9CA3AF");
+
 export interface ComponentProps {
   startDate: Date;
   endDate: Date;
   events: Array<Event>;
+  /*
+   * Server-measured coverage per day. When a day has a reading, it decides
+   * whether that day has data and what its durations are; the `events` array
+   * is then only used for incident overlays. When absent - the dashboard
+   * monitor page, which does not fetch the aggregate - the old event-derived
+   * behaviour applies unchanged.
+   */
+  dayReadings?: Array<DayReading> | undefined;
   height?: number | undefined;
   barColorRules?: Array<BarChartRule> | undefined;
   downtimeEventStatusIds?: Array<ObjectID> | undefined;
@@ -173,6 +215,20 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
     const startOfTheDay: Date = OneUptimeDate.getStartOfDay(todaysDay);
     const endOfTheDay: Date = OneUptimeDate.getEndOfDay(todaysDay);
 
+    /*
+     * The server's reading for this day, when the caller supplied one. It is
+     * matched by instant rather than by index: the window's first bucket is
+     * clipped to the window start, so bucket i is not necessarily day i.
+     */
+    const todaysReading: DayReading | undefined = (
+      props.dayReadings || []
+    ).find((reading: DayReading) => {
+      return (
+        reading.dayStart.getTime() >= startOfTheDay.getTime() &&
+        reading.dayStart.getTime() <= endOfTheDay.getTime()
+      );
+    });
+
     const todaysEvents: Array<Event> = props.events.filter((event: Event) => {
       let doesEventBelongsToToday: boolean = false;
 
@@ -274,32 +330,75 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
       }
     }
 
+    /*
+     * Does this day have data at all?
+     *
+     * With a server reading, coverage is the answer and it is authoritative -
+     * the browser cannot tell a quiet day from a day whose rows were dropped
+     * by the fetch cap. Without one, fall back to the old test.
+     */
+    const hasDataForTheDay: boolean = todaysReading
+      ? todaysReading.coveredSeconds > 0
+      : todaysEvents.length > 0;
+
     // now check bar rules and finalize the color of the bar
 
-    const uptimePercentForTheDay: number =
-      totalUptimeInSeconds + totalDowntimeInSeconds > 0
+    /*
+     * The denominator is what was MEASURED, not the length of the day. A day
+     * only half covered - the day a monitor was created - reports the
+     * percentage of the half we watched rather than being marked down for the
+     * hours nobody was looking.
+     *
+     * The old expression ended in `: 100`, which said "no readings at all
+     * means a perfect day". That is the single line that let a status page
+     * assert uptime for a period it had no data for, so it is gone rather
+     * than adjusted: with no data there is no percentage.
+     */
+    const uptimePercentForTheDay: number = !hasDataForTheDay
+      ? 0
+      : totalUptimeInSeconds + totalDowntimeInSeconds > 0
         ? (totalUptimeInSeconds /
             (totalDowntimeInSeconds + totalUptimeInSeconds)) *
           100
         : 100;
 
-    for (const rules of props.barColorRules || []) {
-      if (uptimePercentForTheDay >= rules.uptimePercentGreaterThanOrEqualTo) {
-        color = rules.barColor;
-        break;
+    /*
+     * Rules are skipped entirely on a day with no data. Otherwise a page
+     * configuring ">= 99% is green" would have that rule matched by a day
+     * nobody measured, which is the very claim this change removes. No-data
+     * outranks operator rules on purpose.
+     */
+    if (hasDataForTheDay) {
+      for (const rules of props.barColorRules || []) {
+        if (uptimePercentForTheDay >= rules.uptimePercentGreaterThanOrEqualTo) {
+          color = rules.barColor;
+          break;
+        }
       }
     }
 
-    if (todaysEvents.length === 1 && !hasEvents) {
+    if (todaysEvents.length >= 1) {
       hasEvents = true;
     }
 
-    if (todaysEvents.length === 1) {
-      hasEvents = true;
-    }
+    /*
+     * THE FIX.
+     *
+     * This used to read: no events today, so paint `defaultBarColor`. That
+     * single line is how a status page claimed uptime for days it had no data
+     * for - `defaultBarColor` is green on the overwhelming majority of pages,
+     * and "no events" was true both for a quiet day and for a day whose rows
+     * the fetch cap had thrown away.
+     *
+     * Now the two are separated. A day with data but no events of its own is
+     * an ordinary good day and still gets the operator's colour. A day with
+     * no data gets the fixed no-data treatment and says so.
+     */
+    hasEvents = hasDataForTheDay;
 
-    if (todaysEvents.length === 0) {
-      hasEvents = false;
+    if (!hasDataForTheDay) {
+      color = NO_DATA_BAR_COLOR;
+    } else if (todaysEvents.length === 0) {
       color = props.defaultBarColor || Green;
     }
 
@@ -315,9 +414,18 @@ const DayUptimeGraph: FunctionComponent<ComponentProps> = (
       className = "w-20 h-" + props.height;
     }
 
-    // Build status durations for tooltip
-    const statusDurations: Array<StatusDuration> = [];
-    for (const key in secondsOfEvent) {
+    /*
+     * Build status durations for the tooltip and the day dialog.
+     *
+     * A server reading wins: its durations are measured over the whole day
+     * server-side, while `secondsOfEvent` can only describe the rows this
+     * browser happened to receive.
+     */
+    const statusDurations: Array<StatusDuration> = todaysReading
+      ? todaysReading.statusDurations
+      : [];
+
+    for (const key in todaysReading ? {} : secondsOfEvent) {
       statusDurations.push({
         label: eventLabels[key] || "Unknown",
         seconds: secondsOfEvent[key] || 0,

package/UI/Components/Markdown.tsx/MarkdownViewer.tsx

@@ -79,6 +79,7 @@ SyntaxHighlighter.registerLanguage("php", php);
 SyntaxHighlighter.registerLanguage("graphql", graphql);
 SyntaxHighlighter.registerLanguage("http", http);
 import DOMPurify from "dompurify";
+import SessionAwareImage from "./SessionAwareImage";
 import OneUptimeDate from "../../../Types/Date";
 import { Theme, useTheme } from "../../Utils/Theme";
 import {
@@ -598,7 +599,7 @@ const MarkdownViewer: FunctionComponent<ComponentProps> = (
           ) : null;
         }
         return (
-          <img
+          <SessionAwareImage
             className="max-w-full h-auto rounded-md border border-gray-200 my-3"
             loading="lazy"
             alt={alt}

package/UI/Components/Markdown.tsx/SessionAwareImage.tsx

@@ -0,0 +1,122 @@
+import UserUtil from "../../Utils/User";
+import React, {
+  FunctionComponent,
+  ReactElement,
+  SyntheticEvent,
+  useCallback,
+  useEffect,
+  useRef,
+  useState,
+} from "react";
+
+/*
+ * Private inline images (pasted into notes, postmortems, runbooks) are served
+ * from this route, and only to a request that carries a session.
+ */
+export const PRIVATE_IMAGE_ROUTE_SEGMENT: string = "/image/access-token/";
+
+export const isPrivateImageUrl: (src: unknown) => boolean = (
+  src: unknown,
+): boolean => {
+  return typeof src === "string" && src.includes(PRIVATE_IMAGE_ROUTE_SEGMENT);
+};
+
+export const withCacheBuster: (src: string, value: string) => string = (
+  src: string,
+  value: string,
+): string => {
+  return `${src}${src.includes("?") ? "&" : "?"}sessionRetry=${encodeURIComponent(value)}`;
+};
+
+export type RefreshSessionFunction = () => Promise<boolean>;
+
+/*
+ * Which session an image may refresh is the app's decision, not this
+ * component's: the same markdown renders on status pages and public
+ * dashboards, where a failed dashboard refresh would log the reader out and
+ * send them to the dashboard's login page - and on a status page served from
+ * the OneUptime host that shares the dashboard's storage, "signed in" in local
+ * storage does not tell the two apart. So nothing is refreshed unless the app
+ * has registered its refresh here (the Dashboard and Admin Dashboard do, at
+ * startup) or the caller passes one.
+ */
+let appRefreshSession: RefreshSessionFunction | null = null;
+
+export const enablePrivateImageSessionRefresh: (
+  refreshSession: RefreshSessionFunction | null,
+) => void = (refreshSession: RefreshSessionFunction | null): void => {
+  appRefreshSession = refreshSession;
+};
+
+export interface ComponentProps
+  extends React.ImgHTMLAttributes<HTMLImageElement> {
+  refreshSession?: RefreshSessionFunction | undefined;
+  isSignedIn?: (() => boolean) | undefined;
+}
+
+/*
+ * An <img> cannot refresh an expired session the way a request through the API
+ * class does: once the access-token cookie lapses, a private image comes back
+ * 404 and stays broken until something else happens to refresh the session.
+ * So on the first failure of a private image, refresh once and load it again -
+ * where the app has opted in (see enablePrivateImageSessionRefresh) and the
+ * user is signed in.
+ */
+const SessionAwareImage: FunctionComponent<ComponentProps> = ({
+  refreshSession,
+  isSignedIn,
+  onError,
+  src,
+  ...imageProps
+}: ComponentProps): ReactElement => {
+  const [currentSrc, setCurrentSrc] = useState<string | undefined>(src);
+  const hasRetriedRef: React.MutableRefObject<boolean> = useRef(false);
+
+  // A new source is a new image, with its own one retry.
+  useEffect(() => {
+    setCurrentSrc(src);
+    hasRetriedRef.current = false;
+  }, [src]);
+
+  const handleError: (event: SyntheticEvent<HTMLImageElement>) => void =
+    useCallback(
+      (event: SyntheticEvent<HTMLImageElement>): void => {
+        const signedIn: boolean = isSignedIn
+          ? isSignedIn()
+          : UserUtil.isLoggedIn();
+
+        const refresh: RefreshSessionFunction | null =
+          refreshSession || appRefreshSession;
+
+        if (
+          !refresh ||
+          hasRetriedRef.current ||
+          !isPrivateImageUrl(src) ||
+          !signedIn
+        ) {
+          onError?.(event);
+          return;
+        }
+
+        hasRetriedRef.current = true;
+
+        void refresh()
+          .then((refreshed: boolean) => {
+            if (refreshed && typeof src === "string") {
+              setCurrentSrc(withCacheBuster(src, Date.now().toString()));
+              return;
+            }
+
+            onError?.(event);
+          })
+          .catch(() => {
+            onError?.(event);
+          });
+      },
+      [src, onError, refreshSession, isSignedIn],
+    );
+
+  return <img {...imageProps} src={currentSrc} onError={handleError} />;
+};
+
+export default SessionAwareImage;

package/UI/Components/ModelList/ModelList.tsx

@@ -37,6 +37,13 @@ export interface ComponentProps<TBaseModel extends BaseModel> {
   fetchRequestOptions?: RequestOptions | undefined;
   customElement?: ((item: TBaseModel) => ReactElement) | undefined;
   noItemsMessage: string;
+  /*
+   * Render nothing, rather than noItemsMessage (or its "No items found."
+   * fallback), when the list loads empty. For a caller that explains an empty
+   * list itself, e.g. from onListLoaded. A search that matches nothing still
+   * says so.
+   */
+  hideEmptyState?: boolean | undefined;
   headerField?: string | ((item: TBaseModel) => ReactElement) | undefined;
   onSelectChange?: ((list: Array<TBaseModel>) => void) | undefined;
   refreshToggle?: string | undefined;
@@ -260,7 +267,10 @@ const ModelList: <TBaseModel extends BaseModel>(
         {error ? <ErrorMessage message={error} /> : <></>}
         {isLoading ? <ComponentLoader /> : <></>}
 
-        {!isLoading && !error && searchedList.length === 0 ? (
+        {!isLoading &&
+        !error &&
+        searchedList.length === 0 &&
+        (Boolean(searchText) || !props.hideEmptyState) ? (
           <ErrorMessage
             message={
               searchText

package/UI/Components/ModelTable/BaseModelTable.tsx

@@ -323,6 +323,18 @@ export interface BaseTableProps<
 
   onFilterApplied?: ((isFilterApplied: boolean) => void) | undefined;
 
+  /**
+   * Called with the query the rows are fetched with - the caller's `query`,
+   * the column filters and the search box, merged exactly as the list request
+   * merges them - on mount and whenever that set of matching rows changes.
+   *
+   * For a surface that summarizes the same rows the table lists (a volume
+   * chart above it, say): reading the filters any other way would let the
+   * summary and the list quietly disagree about what "these events" means.
+   * Sort and page are not part of it; they re-order the same matching set.
+   */
+  onQueryChange?: ((query: Query<TBaseModel>) => void) | undefined;
+
   formSummary?: FormSummaryConfig | undefined;
 
   onAdvancedFiltersToggle?:
@@ -2029,6 +2041,27 @@ const BaseModelTable: <TBaseModel extends BaseModel | AnalyticsBaseModel>(
     clearBulkSelectionState();
   }, [effectiveQueryKey]);
 
+  type BuildEffectiveQueryFunction = () => Query<TBaseModel>;
+
+  // The one merge the list request and `onQueryChange` both read.
+  const buildEffectiveQuery: BuildEffectiveQueryFunction =
+    (): Query<TBaseModel> => {
+      return {
+        ...props.query,
+        ...query,
+        ...buildSearchQueryFragment(),
+      };
+    };
+
+  /*
+   * Keyed on effectiveQueryKey rather than on the query object, which is a
+   * fresh literal every render: a caller that stores what it is handed here
+   * re-renders, and must not be handed the same query again for it.
+   */
+  useEffect(() => {
+    props.onQueryChange?.(buildEffectiveQuery());
+  }, [effectiveQueryKey]);
+
   const fetchItems: PromiseVoidFunction = async (): Promise<void> => {
     setError("");
     setIsLoading(true);
@@ -2047,11 +2080,7 @@ const BaseModelTable: <TBaseModel extends BaseModel | AnalyticsBaseModel>(
         modelType: props.modelType as
           | DatabaseBaseModelType
           | AnalyticsBaseModelType,
-        query: {
-          ...props.query,
-          ...query,
-          ...buildSearchQueryFragment(),
-        },
+        query: buildEffectiveQuery(),
         groupBy: {
           ...props.groupBy,
         },

package/UI/Components/ModelTable/TableView.tsx

@@ -6,7 +6,7 @@ import MoreMenuItem from "../MoreMenu/MoreMenuItem";
 import ModelAPI from "../../Utils/ModelAPI/ModelAPI";
 import { LIMIT_PER_PROJECT } from "../../../Types/Database/LimitMax";
 import SortOrder from "../../../Types/BaseDatabase/SortOrder";
-import API from "../../../Utils/API";
+import API from "../../Utils/API/API";
 import MoreMenuSection from "../MoreMenu/MoreMenuSection";
 import { ButtonStyleType } from "../Button/Button";
 import IconProp from "../../../Types/Icon/IconProp";

package/UI/Components/MonitorGraphs/Uptime.tsx

@@ -2,9 +2,16 @@ import ComponentLoader from "../ComponentLoader/ComponentLoader";
 import ErrorMessage from "../ErrorMessage/ErrorMessage";
 import DayUptimeGraph, {
   BarChartRule,
+  DayReading,
   Event,
   UptimeBarDaySummary,
 } from "../Graphs/DayUptimeGraph";
+import { StatusDuration } from "../Graphs/UptimeDaySummary";
+import Dictionary from "../../../Types/Dictionary";
+import {
+  UptimeDayBucket,
+  UptimeStatusDuration,
+} from "../../../Types/StatusPage/UptimeDailyAggregate";
 import UptimeUtil from "./UptimeUtil";
 import Color from "../../../Types/Color";
 import CommonMonitorEvent from "../../../Utils/Uptime/MonitorEvent";
@@ -27,6 +34,17 @@ export interface ComponentProps {
   height?: number | undefined;
   barColorRules?: Array<StatusPageHistoryChartBarColorRule> | undefined;
   downtimeMonitorStatuses: Array<MonitorStatus> | undefined;
+  /*
+   * Server-measured per-day coverage for THIS monitor.
+   *
+   * The `items` array above arrives under a fetch cap that silently drops
+   * history, so it cannot answer "did we have data for this day". These
+   * buckets can. When absent the graph keeps its old event-derived
+   * behaviour, which is what the dashboard monitor page still uses.
+   */
+  uptimeBuckets?: Array<UptimeDayBucket> | undefined;
+  /* Statuses by id, so a bucket's durations can be given a name and colour. */
+  monitorStatuses?: Array<MonitorStatus> | undefined;
   defaultBarColor: Color;
   incidents?: Array<UptimeBarTooltipIncident> | undefined;
   onBarClick?: (
@@ -62,6 +80,56 @@ const MonitorUptimeGraph: FunctionComponent<ComponentProps> = (
     );
   }, [props.barColorRules]);
 
+  /*
+   * Turn the server's buckets into the graph's per-day readings, resolving
+   * each status id to the name and colour the page already knows.
+   */
+  const dayReadings: Array<DayReading> | undefined = useMemo(() => {
+    if (!props.uptimeBuckets) {
+      return undefined;
+    }
+
+    const statusById: Dictionary<MonitorStatus> = {};
+
+    for (const status of props.monitorStatuses || []) {
+      if (status.id) {
+        statusById[status.id.toString()] = status;
+      }
+    }
+
+    const downtimeIds: Array<string> = (
+      props.downtimeMonitorStatuses || []
+    ).map((status: MonitorStatus) => {
+      return status.id?.toString() || "";
+    });
+
+    return props.uptimeBuckets.map((bucket: UptimeDayBucket): DayReading => {
+      return {
+        dayStart: bucket.bucketStart,
+        daySeconds: bucket.daySeconds,
+        coveredSeconds: bucket.coveredSeconds,
+        statusDurations: bucket.statusDurations.map(
+          (duration: UptimeStatusDuration): StatusDuration => {
+            const statusId: string = duration.monitorStatusId.toString();
+            const status: MonitorStatus | undefined = statusById[statusId];
+
+            return {
+              label: status?.name || "Unknown",
+              seconds: duration.seconds,
+              color: status?.color || props.defaultBarColor,
+              isDowntime: downtimeIds.includes(statusId),
+            };
+          },
+        ),
+      };
+    });
+  }, [
+    props.uptimeBuckets,
+    props.monitorStatuses,
+    props.downtimeMonitorStatuses,
+    props.defaultBarColor,
+  ]);
+
   if (props.isLoading) {
     return <ComponentLoader />;
   }
@@ -80,6 +148,7 @@ const MonitorUptimeGraph: FunctionComponent<ComponentProps> = (
       startDate={props.startDate}
       endDate={props.endDate}
       events={events}
+      dayReadings={dayReadings}
       defaultBarColor={props.defaultBarColor}
       height={props.height}
       barColorRules={barColorRules}

package/UI/Components/TelemetryViewer/TelemetryViewer.tsx

@@ -33,6 +33,18 @@ export interface TelemetryViewerProps<T> {
   error?: string | undefined;
   onRefresh?: (() => void) | undefined;
   emptyMessage?: string | undefined;
+  /*
+   * Replaces the default "No results / try adjusting filters" block when the
+   * list comes back empty.
+   *
+   * For most signals the default is right: an empty list means the filters
+   * are too narrow. For a signal that a project may not be SENDING at all,
+   * it is usually wrong — the reader needs the setup guide, not an
+   * invitation to widen a time range over data that does not exist. Takes
+   * precedence over `emptyMessage`; nothing is rendered around it, so the
+   * caller owns the whole empty area.
+   */
+  emptyContent?: ReactNode;
 
   // -- Layout --
   /** Render one item row in the main list. */
@@ -296,18 +308,22 @@ function TelemetryViewerInner<T>(props: TelemetryViewerProps<T>): ReactElement {
                   <ComponentLoader />
                 </div>
               ) : props.items.length === 0 ? (
-                <div className="flex h-48 flex-col items-center justify-center gap-2 px-6 text-center">
-                  <Icon
-                    icon={IconProp.Search}
-                    className="h-8 w-8 text-gray-300"
-                  />
-                  <p className="text-sm font-medium text-gray-500">
-                    {props.emptyMessage || "No results"}
-                  </p>
-                  <p className="text-xs text-gray-400">
-                    Try adjusting filters or time range.
-                  </p>
-                </div>
+                props.emptyContent !== undefined ? (
+                  <>{props.emptyContent}</>
+                ) : (
+                  <div className="flex h-48 flex-col items-center justify-center gap-2 px-6 text-center">
+                    <Icon
+                      icon={IconProp.Search}
+                      className="h-8 w-8 text-gray-300"
+                    />
+                    <p className="text-sm font-medium text-gray-500">
+                      {props.emptyMessage || "No results"}
+                    </p>
+                    <p className="text-xs text-gray-400">
+                      Try adjusting filters or time range.
+                    </p>
+                  </div>
+                )
               ) : (
                 <ul className="divide-y divide-gray-100">
                   {props.items.map((item: T, index: number) => {

package/UI/Components/TelemetryViewer/components/TelemetryHistogram.tsx

@@ -118,8 +118,15 @@ const TelemetryHistogram: FunctionComponent<TelemetryHistogramProps> = (
   const activeSeries: Array<HistogramSeriesOption> = useMemo(() => {
     const present: Set<string> = new Set<string>();
 
+    /*
+     * A zero-count bucket holds a slot on the time axis (so a quiet stretch
+     * reads as a gap rather than being squeezed out); it is not a sighting
+     * of its series, which draws nothing and must not be legended.
+     */
     for (const bucket of props.buckets) {
-      present.add(bucket.series);
+      if (bucket.count > 0) {
+        present.add(bucket.series);
+      }
     }
 
     return props.series.filter((option: HistogramSeriesOption): boolean => {

package/UI/Components/Tooltip/Tooltip.tsx

@@ -15,6 +15,13 @@ export interface ComponentProps {
   richContent?: ReactElement | undefined;
   // Large collections can wait to create a tooltip until first opened.
   lazy?: boolean | undefined;
+  /*
+   * Rich tooltips are interactive by default, and Tippy mounts an interactive
+   * tooltip inside the trigger's parent - where an overflow-clipped ancestor
+   * (a scrolling grid, say) cuts it off. Pass false for rich content that has
+   * nothing to click: it then mounts on <body> and hides on mouse-out.
+   */
+  interactive?: boolean | undefined;
 }
 
 interface PopupProps extends ComponentProps {
@@ -61,7 +68,7 @@ const TooltipPopup: FunctionComponent<PopupProps> = (
       {...(props.reference
         ? { reference: props.reference, showOnCreate: true }
         : { children: props.children })}
-      interactive={isRich}
+      interactive={props.interactive ?? isRich}
       trigger="mouseenter focus"
       hideOnClick={false}
       maxWidth={isRich ? 380 : 350}