chore(issues): Indicate duration when "Since First Seen" is selected#115533
Conversation
github-actions
Bot
added
the
Scope: Frontend
📊 Type Coverage Diff✅ No new type safety issues introduced. Coverage: 93.58% |
bubbling the first seen date to the trigger makes it more obvious when there's a mismatch between how we calculate that date and the first seen in the sidebar - not a blocker but something to be aware of |
|
@roggenkemper hmmm that's a good point. not sure there's an easy solution to this? i think we want the dropdown to remain consistent with the timeline chart, and the timeline chart definitely needs that query window wider than the actual first seen. maybe there's better text than "since first seen" that we could use? |
|
this might be too confusing for issues that just started since we have a minimum time there. could try removing "since first seen" all together maybe |
|
@amy-chen23 @roggenkemper got @scttcper stamp of approval on discussed approach of making dropdown time range same as actual first seen range, but keeping the query time range and timeline chart range as the extended versions |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
does make this sort of thing more apparent but i don't think it matters that much 
|
Co-authored-by: Scott Cooper <scttcper@gmail.com>
| } | ||
|
|
||
| /** | ||
| * Returns a short-form duration string (e.g. "19d", "3h") without converting to larger units like weeks, matching the sidebar's TimeSince display. |
There was a problem hiding this comment.
Seems like the TimeSince display in the sidebar does use larger units, e.g. on this issue:
Is it possible to just reuse the "2 months" that gets calculated for the sidebar? If that's difficult, I'm fine with always using days (or hours if less than 1 day)
There was a problem hiding this comment.
yup, i can reuse the calculation from the sidebar
This comment was marked as outdated.
This comment was marked as outdated.
| shouldShowSinceFirstSeenOption | ||
| ? { | ||
| [defaultStatsPeriod.statsPeriod]: t( | ||
| '%s (since first seen)', | ||
| getRelativeSummary(defaultStatsPeriod.statsPeriod) | ||
| 'Last %s (since first seen)', | ||
| getRelativeDate(group.firstSeen) | ||
| .replace(/^a (?=\w+$)/, '1 ') | ||
| .replace(/^an (?=\w+$)/, '1 ') | ||
| ), | ||
| } | ||
| : {}), |
There was a problem hiding this comment.
Bug: The custom "since first seen" dropdown label is overwritten by default options when an issue's age matches a standard period like 7d, 14d, or 30d.
Severity: LOW
Suggested Fix
To fix the label overwrite, move the ...props.defaultOptions spread before the custom "since first seen" option is defined within the relativeOptions callback. This will ensure that the custom label takes precedence over the default one for matching time periods, while still allowing other default options to be available.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: static/app/views/issueDetails/streamline/eventDetailsHeader.tsx#L153-L162
Potential issue: When an issue's age aligns with a standard relative period (e.g., 7,
14, or 30 days), the custom "Since First Seen" label in the stats period dropdown is
overwritten. This happens because the `...props.defaultOptions` spread, containing
generic labels like "Last 7 days", is applied after the custom option is defined,
replacing it. This results in a UI inconsistency where the dropdown's trigger button
correctly shows "Since First Seen", but the selected option within the dropdown displays
the generic label, creating a confusing user experience.
There was a problem hiding this comment.
known issue, will need another ticket to address this
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
There are 3 total unresolved issues (including 1 from previous review).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit f5cbc5a. Configure here.
| export function shortenRelativeDate(relativeDate: string): string { | ||
| const match = relativeDate.match(/^(\d+|an?)\s+(\w+)$/); | ||
| if (!match) { | ||
| return '1m'; |
There was a problem hiding this comment.
Fallback produces misleading "1m" for very recent issues
Low Severity
shortenRelativeDate can't parse moment's "a few seconds" output (returned by fromNow(true) for issues less than ~45 seconds old) because the regex /^(\d+|an?)\s+(\w+)$/ only matches two-word strings. The fallback returns '1m' (1 minute), making the trigger display "Since First Seen (1m)" for an issue that's only seconds old. Similarly, the dropdown label's .replace(/^a (?=\w+$)/, '1 ') lookahead won't match "a few seconds" either, resulting in the awkward "Last a few seconds (since first seen)" text.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit f5cbc5a. Configure here.
| if (unit.startsWith('second')) { | ||
| return `${num}s`; | ||
| } | ||
| return '1m'; |
There was a problem hiding this comment.
shortenRelativeDate breaks for non-English locale users
Medium Severity
shortenRelativeDate parses English unit names (startsWith('month'), startsWith('day'), etc.), but getRelativeDate uses moment.fromNow(true) which returns locale-dependent strings. Since Sentry sets moment.locale(languageCode) for non-English users, the output will be e.g. "19 jours" (French) or "19 Tage" (German). All startsWith checks fail for these, so the function always returns the misleading fallback '1m'. The trigger would display "Since First Seen (1m)" for every non-English user regardless of actual duration. The same issue affects the .replace(/^a (?=\w+$)/, '1 ') regex in the dropdown label, which is also English-only.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit f5cbc5a. Configure here.
| .replace(/^a (?=\w+$)/, '1 ') | ||
| .replace(/^an (?=\w+$)/, '1 ') |
There was a problem hiding this comment.
Bug: The regex to format relative time strings fails for multi-word outputs like "a few seconds", leading to incorrect UI text for very new issues.
Severity: LOW
Suggested Fix
Update the regular expression to correctly handle multi-word strings. Instead of using a lookahead that asserts a single word until the end of the string (?=\w+$), a simpler replacement like .replace(/^an? /, '1 ') would correctly handle both "a" and "an" at the beginning of any string, regardless of how many words follow.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: static/app/views/issueDetails/streamline/eventDetailsHeader.tsx#L155-L156
Potential issue: The regular expression used to replace relative time strings starting
with 'a' or 'an' with '1' is too restrictive. The regex `^a (?=\w+$)` uses a lookahead
that requires only a single word to follow the prefix. However, for very recent events,
the `getRelativeDate()` function can return multi-word strings like "a few seconds". The
regex fails to match in these cases, causing the UI to display awkward text like "Since
First Seen (a few seconds)" instead of a numerical equivalent. This bug manifests for
issues that are less than a few minutes old.
Also affects:
static/app/views/issueDetails/streamline/eventDetailsHeader.tsx:191~192
There was a problem hiding this comment.
not an issue. the lookahead (?=\w+$) changes for single-word units (e.g. "a month" --> "1 month"), but ignores multi-word phrases like "a few seconds"
shashjar
left a comment
shashjar
left a comment
There was a problem hiding this comment.
looks good, thanks for sticking with this change!
4 participants
Resolves ID-1271.
On issues page, when filtering by time range, Since First Seen also displays duration.