[$250] Spend Page Displays Submitted Dates in UTC Instead of User’s Local Time

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Needs reproduction
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @sakluger
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Submit a report late in the day near local midnight
2. Navigate to spend page with the Submitted column visible
3. Note the submitted date shown in the Spend list
4. Open the same report
5. Compare the submission timestamp/date shown in report history

Expected Result:

All dates shown on the Spend page should:
Use the user’s local time zone
Submitted date on Spend page should match:
Report history submission date

Actual Result:

Spend page:
Uses UTC date/time for Submitted column
Report history:
Uses local user time
Same report may appear submitted on different calendar days depending on view

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

The screenshot for the issue is in Slack thread

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058324567565448562
• Upwork Job ID: 2058324567565448562
• Last Price Increase: 2026-05-23

[godzillaxbox19982014-lgtm]

looking in to this now as it is just past midnight here 00:08

[MelvinBot]

Proposal

What is the root cause of that problem?

The DateCell component (used by the Spend/Search list for all date columns — date, submitted, approved, posted, exported) formats dates using DateUtils.formatWithUTCTimeZone(), which hardcodes 'UTC' for both parsing and rendering. Report history instead uses datetimeToCalendarTime() → getLocalDateFromDatetime(), which converts to the user's selected timezone. This means the same submission event can show different calendar dates depending on which view the user is looking at.

What changes do you think we should make in order to solve the problem?

Replace DateUtils.formatWithUTCTimeZone() with a timezone-aware formatter in DateCell. The function DateUtils.formatUTCDateTimeToDateInTimezone() already exists and does exactly what's needed — it parses a UTC datetime and formats it in a given timezone. DateCell should accept the user's selected timezone (from Onyx) and call formatUTCDateTimeToDateInTimezone instead.

Important caveat: Transaction created dates may sometimes be date-only strings (YYYY-MM-DD) with no time component, where UTC formatting is intentionally correct to avoid off-by-one shifts. The fix should check whether the datetime string contains a time component before applying timezone conversion — if it's date-only, keep the current UTC behavior.

What alternative solutions did you explore? (Optional)

An alternative would be to modify formatWithUTCTimeZone itself to accept an optional timezone parameter, but that risks unintended side effects across its many call sites. Using the existing formatUTCDateTimeToDateInTimezone function is safer and more explicit.

Investigation details

Data flow:

1. Backend stores report.submitted as a UTC datetime string
2. SearchUIUtils reads report?.submitted raw
3. ExpenseReportListItemRowWide passes it to DateCell
4. DateCell calls formatWithUTCTimeZone(date, format) — hardcoded to UTC
5. Report history uses datetimeToCalendarTime → getLocalDateFromDatetime which uses currentSelectedTimezone

Example scenario: A user in UTC-8 submits a report at 11 PM local time (May 22). The backend stores this as 7 AM May 23 UTC. The Spend page shows "May 23" (UTC), but report history shows "May 22" (local time).

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-23 23:21:36 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

The Spend page can show a report's Submitted date on a different calendar day than the same submission event in report history. This happens for reports submitted near a timezone day boundary because the Spend/Search table renders the report lifecycle timestamp as a UTC date, while report history renders the timestamp in the user's selected timezone.

What is the root cause of that problem?

The Spend/Search table sends report lifecycle datetimes through the generic DateCell UTC formatter.

For transaction rows, SearchUIUtils keeps the raw report lifecycle fields, report.submitted and report.approved, on the list item, while TransactionItemRowWide passes those values directly into DateCell for the Submitted and Approved columns. The Exported column also passes the latest exported report action timestamp into DateCell.

App/src/libs/SearchUIUtils.ts

Lines 1189 to 1193 in a9c3c31

	const submitted = report?.submitted;
	const approved = report?.approved;
	// Posted date is in the YYYYMMDD format, so we format it to YYYY-MM-DD here since JS's Date constructor interprets it as an invalid date.
	const posted = !transactionItem?.posted ? '' : `${transactionItem?.posted.slice(0, 4)}-${transactionItem?.posted.slice(4, 6)}-${transactionItem?.posted.slice(6, 8)}`;

App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

Lines 190 to 239 in a9c3c31

	case CONST.SEARCH.TABLE_COLUMNS.SUBMITTED:
	return (
	<View
	key={column}
	style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.SUBMITTED, {isDateColumnWide, isSubmittedColumnWide})]}
	>
	<DateCell
	date={report?.submitted ?? ''}
	showTooltip={shouldShowTooltip}
	isLargeScreenWidth
	/>
	</View>
	);
	case CONST.SEARCH.TABLE_COLUMNS.APPROVED:
	return (
	<View
	key={column}
	style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.APPROVED, {isApprovedColumnWide})]}
	>
	<DateCell
	date={report?.approved ?? ''}
	showTooltip={shouldShowTooltip}
	isLargeScreenWidth
	/>
	</View>
	);
	case CONST.SEARCH.TABLE_COLUMNS.POSTED:
	return (
	<View
	key={column}
	style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.POSTED, {isPostedColumnWide})]}
	>
	<DateCell
	date={transactionItem.posted ?? ''}
	showTooltip={shouldShowTooltip}
	isLargeScreenWidth
	/>
	</View>
	);
	case CONST.SEARCH.TABLE_COLUMNS.EXPORTED:
	return (
	<View
	key={column}
	style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.EXPORTED, {isExportedColumnWide})]}
	>
	<DateCell
	date={transactionItem.exported ?? ''}
	showTooltip={shouldShowTooltip}
	isLargeScreenWidth
	/>

For grouped expense-report rows, ExpenseReportListItemRowWide also passes item.submitted, item.approved, and item.exported directly into DateCell.

App/src/components/Search/SearchList/ListItem/ExpenseReportListItemRow/ExpenseReportListItemRowWide.tsx

Lines 67 to 91 in a9c3c31

	[CONST.SEARCH.TABLE_COLUMNS.SUBMITTED]: (
	<View style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.SUBMITTED, {isSubmittedColumnWide: item.shouldShowYearSubmitted})]}>
	<DateCell
	date={item.submitted ?? ''}
	showTooltip
	isLargeScreenWidth
	/>
	</View>
	),
	[CONST.SEARCH.TABLE_COLUMNS.APPROVED]: (
	<View style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.APPROVED, {isApprovedColumnWide: item.shouldShowYearApproved})]}>
	<DateCell
	date={item.approved ?? ''}
	showTooltip
	isLargeScreenWidth
	/>
	</View>
	),
	[CONST.SEARCH.TABLE_COLUMNS.EXPORTED]: (
	<View style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.EXPORTED, {isExportedColumnWide: item.shouldShowYearExported})]}>
	<DateCell
	date={item.exported ?? ''}
	showTooltip
	isLargeScreenWidth
	/>

DateCell always calls DateUtils.formatWithUTCTimeZone(), and that helper parses/formats with the UTC timezone. So a UTC server datetime such as 2026-05-23 23:30:00 still renders as May 23 in the Spend table.

App/src/components/Search/SearchList/ListItem/DateCell.tsx

Line 27 in a9c3c31

const formattedDate = DateUtils.formatWithUTCTimeZone(date, DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT);

App/src/libs/DateUtils.ts

Lines 692 to 699 in a9c3c31

	function formatWithUTCTimeZone(datetime: string, dateFormat: string = CONST.DATE.FNS_FORMAT_STRING) {
	const date = toDate(datetime, {timeZone: 'UTC'});
	if (isValid(date)) {
	return tzFormat(toZonedTime(date, 'UTC'), dateFormat);
	}
	return '';

Report history uses a different path: ReportActionItemDate calls datetimeToCalendarTime(), and LocaleContextProvider wires that helper to the current user's effective timezone via DateUtils.getLocalDateFromDatetime(). For the same example timestamp, a user in Asia/Kolkata sees May 24 in report history.

App/src/pages/inbox/report/ReportActionItemDate.tsx

Lines 12 to 19 in a9c3c31

	function ReportActionItemDate({created}: ReportActionItemDateProps) {
	const {datetimeToCalendarTime} = useLocalize();
	const styles = useThemeStyles();
	// It is used to force re-render of component that display relative time, ensuring they update correctly when the date changes (e.g., at midnight).
	useOnyx(ONYXKEYS.CURRENT_DATE);
	return <Text style={[styles.chatItemMessageHeaderTimestamp]}>{datetimeToCalendarTime(created, false, false)}</Text>;

App/src/components/LocaleContextProvider.tsx

Lines 125 to 139 in a9c3c31

	const selectedTimezone = currentUserPersonalDetails?.timezone?.selected;
	const effectiveTimezone = selectedTimezone ?? CONST.DEFAULT_TIME_ZONE.selected;
	const collator = new Intl.Collator(currentLocale, COLLATOR_OPTIONS);
	const translate: LocaleContextProps['translate'] = (path, ...parameters) => translateLocalize(currentLocale, path, ...parameters);
	const numberFormat: LocaleContextProps['numberFormat'] = (number, options) => format(currentLocale, number, options);
	const getLocalDateFromDatetime: LocaleContextProps['getLocalDateFromDatetime'] = (datetime, currentSelectedTimezone) =>
	DateUtils.getLocalDateFromDatetime(currentLocale, currentSelectedTimezone ?? effectiveTimezone, datetime);
	const datetimeToRelative: LocaleContextProps['datetimeToRelative'] = (datetime) => DateUtils.datetimeToRelative(currentLocale, datetime, effectiveTimezone);
	const datetimeToCalendarTime: LocaleContextProps['datetimeToCalendarTime'] = (datetime, includeTimezone, isLowercase = false) =>
	DateUtils.datetimeToCalendarTime(currentLocale, datetime, effectiveTimezone, includeTimezone, isLowercase);

That difference is why the same report can show one submitted date in the Spend list and another submitted date in report history.

What changes do you think we should make in order to solve the problem?

Add an explicit local-time display mode to DateCell, defaulting to the current UTC behavior.

The local mode should only localize values that are real datetimes, not date-only strings. That guard is important because transaction Date and Posted values are calendar dates. Posted is normalized from YYYYMMDD to YYYY-MM-DD before rendering. Shifting those through a timezone would create a new off-by-one bug for users west of UTC.

A concrete implementation:

1. Add an optional DateCell prop such as shouldUseLocalTimeZone, defaulting to false.
2. In DateCell, detect whether the value contains a time component, for example YYYY-MM-DD HH:mm:ss, YYYY-MM-DDTHH:mm:ss, or the same shapes with milliseconds.
3. When shouldUseLocalTimeZone is true and the value has a time component, format useLocalize().getLocalDateFromDatetime(date) with date-fns format and the existing Month Day / Month Day, Year formats.
4. Otherwise keep the current DateUtils.formatWithUTCTimeZone path.
5. Derive the "show year" format decision from the same local Date object when local mode is used, so datetimes near New Year do not get a UTC-vs-local mismatch.

Then opt in only the report lifecycle timestamp columns:

• TransactionItemRowWide: Submitted, Approved, and Exported.
• ExpenseReportListItemRowWide: Submitted, Approved, and Exported.

Keep transaction Date and Posted on the default UTC/date-only path.

For complete New Year boundary correctness, make the lifecycle column width/year flags use the same local converted date as the rendered cell. That can be done by threading the local datetime helper from the Search entry points into the lifecycle-year preprocessing, or by passing an explicit local-mode year/format decision from the row layer into DateCell. The key requirement is that the width flag and displayed format are derived from the same localized lifecycle date.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add focused coverage for the date cell or Spend row rendering with a mocked current user timezone:

• Given date "2026-05-23 23:30:00", timezone Asia/Kolkata, and local-time mode enabled, the Submitted cell renders May 24.
• Given the same datetime without local-time mode, DateCell keeps the current UTC behavior and renders May 23.
• Given date "2026-05-23" with local-time mode enabled and timezone America/Los_Angeles, the cell still renders May 23, proving date-only values do not shift.
• Row-level tests confirm Submitted, Approved, and Exported opt into local-time mode, while Date and Posted do not.

What alternative solutions did you explore?

One option is to change DateCell to always use the user's timezone. I would avoid that because the same component also renders date-only expense and posted dates, and those should remain stable calendar dates.

Another option is to pre-format submitted in SearchUIUtils. I would avoid that because the search transformation layer still needs raw values for sorting and reuse, and it does not currently own the same locale/timezone formatting context as report history. Keeping the timezone choice explicit at the display boundary makes the change narrower and easier to audit.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Ollyws (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022058324567565448562

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Spend page (Web/Desktop), the Submitted column shows dates formatted in UTC, so a report submitted near local midnight can appear on a different calendar day than what the report history (which uses the user's local timezone) shows. Expected: the Submitted column should match the report history and use the user's local timezone.

What is the root cause of that problem?

In src/components/Search/SearchList/ListItem/DateCell.tsx:27, every Spend-page date cell (including the Submitted column) is formatted via DateUtils.formatWithUTCTimeZone(date, …). That helper, defined at src/libs/DateUtils.ts:692, explicitly does toDate(datetime, {timeZone: 'UTC'}) + toZonedTime(date, 'UTC'), so a submitted datetime like 2024-XX-XX 23:30:00 UTC is rendered as that UTC day instead of being converted into the viewer's timezone. Report history, by contrast, runs through getLocalDateFromDatetime with currentSelectedTimezone, which is why the two views disagree near midnight.

What changes do you think we should make in order to solve the problem?

1. In src/components/Search/SearchList/ListItem/DateCell.tsx, stop using formatWithUTCTimeZone for datetime values that have a meaningful clock time (submitted/approved). Use the existing DateUtils.formatInTimeZoneWithFallback (defined at DateUtils.ts:929, already exported) with DateUtils.getCurrentTimezone() so the day shown matches the local-time day — no new helper needed.
2. Keep transaction created and posted (date-only YYYY-MM-DD values) on the existing UTC path since they have no time component, OR route them through the same helper — either way they will render the same calendar day. Verify against getFromToSearchData in src/libs/SearchUIUtils.ts:1186-1193 where date/posted are produced.
3. Audit the other consumers that feed DateCell (ExpenseReportListItemRowWide.tsx, TransactionListItemWide.tsx) for submitted/approved/exported columns and the year-banner logic in SearchUIUtils.ts (e.g. doesDateBelongToAPastYear(report.submitted) around lines 1483/1527/1828) so the "show year" decision also uses the local-time year, not the UTC year.

What alternative solutions did you explore? (Optional)

Converting the value once in SearchUIUtils.getFromToSearchData before it reaches DateCell — rejected because other date fields piped through the same cell (e.g. posted) are date-only and would be corrupted by a TZ shift; centralizing the fix in DateCell keeps the conversion next to the format call.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The Spend table renders the Submitted column (and the other workflow-timestamp columns) through DateCell, which formats the value with DateUtils.formatWithUTCTimeZone:

App/src/components/Search/SearchList/ListItem/DateCell.tsx

Line 27 in a9c3c31

const formattedDate = DateUtils.formatWithUTCTimeZone(date, DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT);

formatWithUTCTimeZone explicitly pins the rendered day to the UTC zone via toZonedTime(date, 'UTC'):

App/src/libs/DateUtils.ts

Lines 692 to 700 in a9c3c31

	function formatWithUTCTimeZone(datetime: string, dateFormat: string = CONST.DATE.FNS_FORMAT_STRING) {
	const date = toDate(datetime, {timeZone: 'UTC'});
	if (isValid(date)) {
	return tzFormat(toZonedTime(date, 'UTC'), dateFormat);
	}
	return '';
	}

report.submitted is a full UTC datetime (it carries a time component), so for a report submitted near local midnight the UTC calendar day differs from the user's local calendar day.

Report history, by contrast, formats the same timestamp through datetimeToCalendarTime, which converts to the user's selected timezone before formatting:

App/src/pages/inbox/report/ReportActionItemDate.tsx

Lines 12 to 19 in a9c3c31

	function ReportActionItemDate({created}: ReportActionItemDateProps) {
	const {datetimeToCalendarTime} = useLocalize();
	const styles = useThemeStyles();
	// It is used to force re-render of component that display relative time, ensuring they update correctly when the date changes (e.g., at midnight).
	useOnyx(ONYXKEYS.CURRENT_DATE);
	return <Text style={[styles.chatItemMessageHeaderTimestamp]}>{datetimeToCalendarTime(created, false, false)}</Text>;

Both datetimeToCalendarTime and getLocalDateFromDatetime resolve the zone from effectiveTimezone (personalDetails.timezone.selected, falling back to the default):

App/src/components/LocaleContextProvider.tsx

Lines 125 to 139 in a9c3c31

	const selectedTimezone = currentUserPersonalDetails?.timezone?.selected;
	const effectiveTimezone = selectedTimezone ?? CONST.DEFAULT_TIME_ZONE.selected;
	const collator = new Intl.Collator(currentLocale, COLLATOR_OPTIONS);
	const translate: LocaleContextProps['translate'] = (path, ...parameters) => translateLocalize(currentLocale, path, ...parameters);
	const numberFormat: LocaleContextProps['numberFormat'] = (number, options) => format(currentLocale, number, options);
	const getLocalDateFromDatetime: LocaleContextProps['getLocalDateFromDatetime'] = (datetime, currentSelectedTimezone) =>
	DateUtils.getLocalDateFromDatetime(currentLocale, currentSelectedTimezone ?? effectiveTimezone, datetime);
	const datetimeToRelative: LocaleContextProps['datetimeToRelative'] = (datetime) => DateUtils.datetimeToRelative(currentLocale, datetime, effectiveTimezone);
	const datetimeToCalendarTime: LocaleContextProps['datetimeToCalendarTime'] = (datetime, includeTimezone, isLowercase = false) =>
	DateUtils.datetimeToCalendarTime(currentLocale, datetime, effectiveTimezone, includeTimezone, isLowercase);

So the Spend page shows a UTC day while report history shows the local day, and the two disagree near midnight.

What changes do you think we should make in order to solve the problem?

Format the workflow timestamps in DateCell using the user's selected timezone — the same getLocalDateFromDatetime path report history already uses — so the displayed day matches exactly. I add a shouldUseLocalTimeZone prop (default false) so the transaction Date column is untouched.

-function DateCell({date, showTooltip, isLargeScreenWidth, suffixText, canEdit, onSave}: DateCellProps) {
+function DateCell({date, showTooltip, isLargeScreenWidth, suffixText, shouldUseLocalTimeZone = false, canEdit, onSave}: DateCellProps) {
     const styles = useThemeStyles();
+    const {getLocalDateFromDatetime} = useLocalize();
     ...
-    const formattedDate = DateUtils.formatWithUTCTimeZone(date, DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT);
+    const dateFormat = DateUtils.doesDateBelongToAPastYear(date) ? CONST.DATE.MONTH_DAY_YEAR_ABBR_FORMAT : CONST.DATE.MONTH_DAY_ABBR_FORMAT;
+    const formattedDate = shouldUseLocalTimeZone && date ? format(getLocalDateFromDatetime(date), dateFormat) : DateUtils.formatWithUTCTimeZone(date, dateFormat);

This adds two imports (format from date-fns, useLocalize from @hooks/useLocalize) and the shouldUseLocalTimeZone?: boolean field on DateCellProps. The && date guard keeps an empty value blank (getLocalDateFromDatetime('') would otherwise return now); using useLocalize().getLocalDateFromDatetime guarantees the Spend column resolves the identical effectiveTimezone report history uses, so they can never disagree.

Then pass the prop to the workflow-timestamp cells. For example the Submitted cell:

                 <DateCell
                     date={item.submitted ?? ''}
+                    shouldUseLocalTimeZone
                     showTooltip
                     isLargeScreenWidth
                 />

The same one-line prop applies to the Approved and Exported cells in ExpenseReportListItemRowWide.tsx and to the Submitted / Approved / Posted / Exported cells in TransactionItemRowWide.tsx. The transaction Date column is deliberately left on UTC formatting because it is a user-picked calendar date with no time component (and it's the only editable cell, feeding DatePickerModal value={date}), so converting it would shift the day. The narrow layout only renders the Date column, so it needs no change.

What alternative solutions did you explore? (Optional)

• Flip DateCell to local time unconditionally (no prop). Rejected: it would also convert the transaction Date column, which is a date-only value the user picked. For users in a negative UTC offset an expense dated "May 23" would render "May 22", introducing a new bug while fixing this one.
• Convert at the data layer in getTransactionItemCommonFormattedProperties. Rejected: report.submitted there also drives the shouldShowYearSubmitted width/format decision and the column sort; rewriting the stored string risks an inconsistent sort and mutates the raw value other consumers read. Converting only at the display layer keeps the source value intact.

[lxyct825-ops]

Proposal

Please re-state the problem that we are trying to solve in this issue.

[$250] Spend Page Displays Submitted Dates in UTC Instead of User’s Local Time

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

What changes do you think we should make in order to solve the problem?

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.