@punch-in/strapi-admin 1.2.2 → 1.2.3

package/admin/src/app.js

@@ -55,6 +55,65 @@ import history from './utils/history';
 
 import plugins from './plugins';
 
+// Retry on 504 (Gateway Timeout): the tenant Lambda backends occasionally hit
+// a concurrent cold-start race (multiple containers contending for the same
+// SQLite file - SQLITE_BUSY) where the Lambda crashes before doing any work
+// at all, surfaced to the browser as a 504. That's almost always transient -
+// a follow-up request a few seconds later succeeds once one container wins.
+//
+// Also retries on a *rejected* fetch, not just a resolved 504: API Gateway's
+// own gateway-generated error responses (this same 504, plus throttles etc.)
+// never reach Strapi, so its CORS middleware never adds the usual headers -
+// the browser then discards the cross-origin response as a CORS failure and
+// fetch() rejects instead of resolving with the status code, invisible to
+// the `response.status === 504` check below. (The per-tenant CloudFormation
+// template's GatewayResponseDefault4xx/5xx now add a CORS header to those
+// gateway-generated responses too, so this should mostly stop happening -
+// this is a second, independent safety net for whatever slips through, e.g.
+// a genuinely dropped connection that never got any response to add headers
+// to in the first place.)
+//
+// Installed once, globally, here at the app's entry point (before anything
+// else runs) rather than inside strapi-helper-plugin's request() - that
+// package only ships a prebuilt dist bundle with no source to patch, and
+// request() calls window.fetch directly, so wrapping fetch here covers every
+// request() call (and any other direct fetch caller) with zero changes to
+// strapi-helper-plugin or any of its hundreds of call sites.
+//
+// Note: this retries every method, including POST/PUT/DELETE. A 504 (or a
+// rejected fetch) here has only ever been observed as "the Lambda crashed
+// before it did anything" (see above), not "the write succeeded but the
+// response was lost" - but that's this app's specific failure mode, not a
+// general guarantee, so it's worth knowing if this ever gets reused
+// somewhere with different backend behavior.
+const RETRY_DELAYS_MS = [2000, 4000, 8000];
+const nativeFetch = window.fetch.bind(window);
+
+const attemptFetch = (...args) =>
+  nativeFetch(...args).then(
+    response => ({ response }),
+    error => ({ error })
+  );
+
+window.fetch = async (...args) => {
+  let { response, error } = await attemptFetch(...args);
+
+  for (
+    let i = 0;
+    (error || response.status === 504) && i < RETRY_DELAYS_MS.length;
+    i += 1
+  ) {
+    await new Promise(resolve => setTimeout(resolve, RETRY_DELAYS_MS[i]));
+    ({ response, error } = await attemptFetch(...args));
+  }
+
+  if (error) {
+    throw error;
+  }
+
+  return response;
+};
+
 const strapi = Strapi();
 
 const pluginsReducers = {};

package/admin/src/containers/Admin/Logout/components.js

@@ -64,9 +64,25 @@ const Wrapper = styled.div`
   }
 
   .dropDownContent {
-    z-index: 8;
-    top: -3px !important;
+    /* Was 8 - lower than LeftMenu's sidebar (z-index 10) and even this
+       component's own toggle button (z-index 9 above), so the open dropdown
+       could render underneath either. The earlier fix (3bc5191a) raised the
+       outer NavTopRightWrapper to 15 to outrank the sidebar but missed this
+       nested value. */
+    z-index: 1000;
+    /* Popper.js (v1, via reactstrap 8's react-popper) computes a broken
+       translate3d offset for this toggle - even after disabling its flip
+       modifier and trying positionFixed, it still placed the menu at
+       negative Y (off-screen above the viewport) or off to the right past
+       the viewport edge. Forcing static positioning here overrides Popper's
+       inline transform/position outright: the menu just hangs directly
+       below its toggle button, which is all this fixed, always-in-the-
+       same-spot navbar dropdown ever needs. */
+    position: absolute !important;
+    transform: none !important;
+    top: 100% !important;
     left: auto !important;
+    right: 0 !important;
     min-width: 190px;
     margin: 0 !important;
     padding: 0;

package/admin/src/containers/Admin/Logout/index.js

@@ -38,12 +38,21 @@ const Logout = ({ history: { push } }) => {
 
   return (
     <Wrapper>
-      <ButtonDropdown isOpen={isOpen} toggle={toggle}>
+      <ButtonDropdown isOpen={isOpen} toggle={toggle} direction="down">
         <DropdownToggle>
           {displayName}
           <FontAwesomeIcon icon="caret-down" />
         </DropdownToggle>
-        <DropdownMenu className="dropDownContent">
+        {/* flip={false}: this toggle lives in a position:fixed, top:0 navbar with
+            no room above it. Popper's flip modifier was misjudging available space
+            in that context and auto-flipping the menu to open upward, pushing it to
+            negative Y coordinates - technically "visible" (not display:none, correct
+            z-index) but rendered entirely off-screen above the viewport. Popper's
+            translate3d offset stayed wrong (and got worse under positionFixed) even
+            after this, so components.js also forces static CSS positioning below,
+            overriding Popper's transform outright rather than fighting its popper.js
+            v1 coordinate math in this nested-fixed-position navbar. */}
+        <DropdownMenu className="dropDownContent" flip={false}>
           <DropdownItem onClick={handleGoToMe} className="item">
             <FormattedMessage id="app.components.Logout.profile" />
           </DropdownItem>

package/package.json

@@ -139,5 +139,5 @@
     "develop:ce": "STRAPI_DISABLE_EE=true webpack-dev-server --config webpack.config.dev.js",
     "test": "echo \"no tests yet\""
   },
-  "version": "1.2.2"
+  "version": "1.2.3"
 }