Followup with technical details.
All code examples here were pulled from Chrome developer tools which relies on creating a sourcemap from the minified javascript files provided to the browser to render the site. These are publicly accessible to anyone with technical knowhow, but if you don't want them exposed here, feel free to delete this post after remitting to appropriate teams.
The issue impacts any dashboard page that needs to utilize a sandbox credential/app e.g. "Default Application" for a user in the United States accessing an account based in another country with English as the display language (as far as I know).
Whenever a data table is rendered, either to show apps or to show api call logs / webhook events, the timestamp passed by the backend needs to be localized.
Render app/credentials
// Render a row for each app -flowio
useEffect(() => {
const formattedRowsForDataTable = sandboxApps?.map((app, i) =>
buildDataTableRow(app, i),
)
setApps(formattedRowsForDataTable)
}, [sandboxApps])
// Extracted from the buildDataTableRow function -flowio
[CREATED_DATE]: {
value: formatRestApiAppsEpoch(app.timeCreated),
}
export function formatRestApiAppsEpoch(epochTimestamp) {
// redacted -flowio
const createdDate = moment.unix(epochInSeconds).format('DD MMM YYYY HH:mm:ss')
const formatCreatedDate = formatDate(createdDate)
return formatCreatedDate
}
API call logs
// Display api call logs, each row is a different call record with a timestamp -flowio
export function formatApiCallsRows(rows) {
if (!rows) return []
const formattedRows = rows.map((obj) => {
// redacted -flowio
let create_time = formatDate(obj.create_time)
// redacted -flowio
return { ...obj, identifier, event_type, create_time }
})
return formattedRows
}
This formatDate function seems to have a hardcoded value of en-US when viewed in dev tools. This is likely a result of serverside rendering based on the accept language header or some other aspect of my account profile. This is supposed to be mapped to a language bundle loaded to the UI application as part of initial rendering.
export const formatDate = (date) => {
let worldReady = new WorldReady('en-US')
let dateTimeFormatter = new DateTimeFormat(worldReady, {
style: 'datetime-short',
timeZone: 'America/Los_Angeles',
})
return dateTimeFormatter.format(new Date(date))
}
var WorldReady = function WorldReady(locale) {
var _main;
if (process.env.NODE_ENV !== "production") {
assert(isWorldReadyLoadCalled, "Load WorldReady metadata first. Please read " + "https://github.paypal.com/pages/Globalization-R/worldready-js" + "/about-load-worldready-data.html");
}
// redacted -flowio
this.globalize = new Globalize(locale);
var cldr = this.globalize.cldr;
// redacted -flowio
};
function Globalize( locale ) {
if ( !( this instanceof Globalize ) ) {
return new Globalize( locale );
}
validateParameterPresence( locale, "locale" );
validateParameterTypeLocale( locale, "locale" );
// This is where the error occurs because en-US isn't an available bundlemap - flowio
this.cldr = alwaysCldr( locale );
validateLikelySubtags( this.cldr );
}
However, en-US is not available based on the data loaded to the UI to populate WorldReady's language mappings. Instead it expects `en-{AccountCountry}`.
// Values available to cldr when the app is being loaded -flowio
_availableBundleMap: {en-CA: 'en-CA'}
_availableBundleMapQueue: ['en-US']
// Error returned after evaluating the cldr -flowio
"Error: Could not find likelySubtags for en-US\n at https://www.paypalobjects.com/web/res/ab4/3460025f720bdb3bbe604bcb8df77/js/client/bundle.js:53290:2064\n at Array.forEach (<anonymous>)\n at R (https://www.paypalobjects.com/web/res/ab4/3460025f720bdb3bbe604bcb8df77/js/client/bundle.js:53290:1829)\n at t (https://www.paypalobjects.com/web/res/ab4/3460025f720bdb3bbe604bcb8df77/js/client/bundle.js:53290:1973)\n at u.init (https://www.paypalobjects.com/web/res/ab4/3460025f720bdb3bbe604bcb8df77/js/client/bundle.js:53290:4231)\n at N.init (https://www.paypalobjects.com/we[Removed. Phone #s not permitted])\n at N.init (https://www.paypalobjects.com/web/res/ab4/3460025f720[Removed. Phone #s not permitted])\n at new u (https://www.paypalobjects.com/web/res/ab4/3460025f720[Removed. Phone #s not permitted]84)\n at g (https://www.paypalobjects.com/web/res/ab4/3460025f720[Removed. Phone #s not permitted]62)\n at new O (https://www.paypalobjects.com/web/res/ab4/3460025f720bdb3bbe604bcb8df77/js/client/bundle.js:53318:2908)"
If you set a breakpoint in the devtools in the Globalize logic and change both the `Globalize(locale)` and `Cldr._availableBundleMapQueue` to be `en-{AccountCountry}` instead of en-US, the page will load properly, indicating that this is the root cause.
