[BUG] - Navbar

NextUI Version
2.2.10
Describe the bug
When clicking on the dropdown component it generates an Unhandled Runtime Error, i used the code provided here: https://nextui.org/docs/components/navbar (Navbar with dropdown)
here are the error log as seen in Chrome Dev Tools Console:
app-index.js:33 Warning: Cannot update a component (HotReload) while rendering a different component (ForwardRef(NextUI.Menu)). To locate the bad setState() call inside ForwardRef(NextUI.Menu), follow the stack trace as described in https://reactjs.org/link/setstate-in-render
at Menu (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/menu/dist/chunk-B24OILC2.mjs:36:67)
at $9bf71ea28793e738$export$20e40289641fbbb6 (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/focus/dist/import.mjs:109:21)
at div
at div
at div
at MotionComponent (webpack-internal:///(app-pages-browser)/./node_modules/framer-motion/dist/es/motion/index.mjs:49:65)
at eval (webpack-internal:///(app-pages-browser)/./node_modules/react-remove-scroll/dist/es2015/UI.js:23:50)
at div
at eval (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/popover/dist/chunk-ARECNDSB.mjs:31:11)
at DropdownMenu (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/dropdown/dist/chunk-SXHEBZUY.mjs:21:99)
at $9bf71ea28793e738$export$20e40289641fbbb6 (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/focus/dist/import.mjs:109:21)
at $f1ab8c75478c6f73$export$cf75428e0b9ed1ea (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/interactions/dist/import.mjs:747:64)
at $337b884510726a0d$export$c6fdb837b070b4ff (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/overlays/dist/import.mjs:1421:75)
at PresenceChild (webpack-internal:///(app-pages-browser)/./node_modules/framer-motion/dist/es/components/AnimatePresence/PresenceChild.mjs:15:26)
at AnimatePresence (webpack-internal:///(app-pages-browser)/./node_modules/framer-motion/dist/es/components/AnimatePresence/index.mjs:72:28)
at eval (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/popover/dist/chunk-I7AEEVL3.mjs:23:11)
at Dropdown (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/dropdown/dist/chunk-FHP3QEBP.mjs:19:11)
at ul
at eval (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/navbar/dist/chunk-PSG7VTZC.mjs:20:11)
at header
at nav
at eval (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/navbar/dist/chunk-CMNN5TJ7.mjs:27:11)
at div
at f (webpack-internal:///(app-pages-browser)/./node_modules/next-themes/dist/index.module.js:8:597)
at $ (webpack-internal:///(app-pages-browser)/./node_modules/next-themes/dist/index.module.js:8:348)
at $ea8dcbcb9ea1b556$export$323e4fc2fa4753fb (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/utils/dist/import.mjs:508:21)
at div
at $f57aed4a881a3485$var$OverlayContainerDOM (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/overlays/dist/import.mjs:1069:54)
at $f57aed4a881a3485$export$178405afcd8c5eb (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/overlays/dist/import.mjs:1036:21)
at $f57aed4a881a3485$export$bf688221f59024e5
at $18f2051aff69b9bf$export$a54013f0d02a8f82 (webpack-internal:///(app-pages-browser)/./node_modules/@react-aria/i18n/dist/real-module.mjs:170:19)
at NextUIProvider (webpack-internal:///(app-pages-browser)/./node_modules/@nextui-org/system/dist/chunk-HRMF5D3P.mjs:15:3)
at Providers (webpack-internal:///(app-pages-browser)/./src/app/providers.tsx:19:11)
at body
at html
at InnerLayoutRouter (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/layout-router.js:241:11)
at RedirectErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/not-found-boundary.js:54:9)
at NotFoundBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/not-found-boundary.js:62:11)
at LoadingBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/layout-router.js:338:11)
at ErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/error-boundary.js:130:11)
at InnerScrollAndFocusHandler (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/layout-router.js:152:9)
at ScrollAndFocusHandler (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/layout-router.js:227:11)
at RenderFromTemplateContext (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/render-from-template-context.js:15:44)
at OuterLayoutRouter (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/layout-router.js:348:11)
at RedirectErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/not-found-boundary.js:54:9)
at NotFoundBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/not-found-boundary.js:62:11)
at DevRootNotFoundBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/dev-root-not-found-boundary.js:32:11)
at ReactDevOverlay (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/react-dev-overlay/internal/ReactDevOverlay.js:66:9)
at HotReload (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/react-dev-overlay/hot-reloader-client.js:297:11)
at Router (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/app-router.js:158:11)
at ErrorBoundaryHandler (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/error-boundary.js:100:9)
at ErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/error-boundary.js:130:11)
at AppRouter (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/app-router.js:441:13)
at ServerRoot (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/app-index.js:127:11)
at RSCComponent
at Root (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/app-index.js:143:11)
window.console.error @ app-index.js:33
Show 1 more frame
Show less
import.mjs:219 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at HTMLUnknownElement.callCallback (react-dom.development.js:20367:14)
at Object.invokeGuardedCallbackImpl (react-dom.development.js:20416:16)
at invokeGuardedCallback (react-dom.development.js:20491:29)
at beginWork (react-dom.development.js:26669:7)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at performSyncWorkOnRoot (react-dom.development.js:24633:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
redirect-boundary.js:56 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at performSyncWorkOnRoot (react-dom.development.js:24633:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
not-found-boundary.js:22 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at performSyncWorkOnRoot (react-dom.development.js:24633:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
redirect-boundary.js:56 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at performSyncWorkOnRoot (react-dom.development.js:24633:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
not-found-boundary.js:22 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at performSyncWorkOnRoot (react-dom.development.js:24633:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
import.mjs:219 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at HTMLUnknownElement.callCallback (react-dom.development.js:20367:14)
at Object.invokeGuardedCallbackImpl (react-dom.development.js:20416:16)
at invokeGuardedCallback (react-dom.development.js:20491:29)
at beginWork (react-dom.development.js:26669:7)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at recoverFromConcurrentError (react-dom.development.js:24381:20)
at performSyncWorkOnRoot (react-dom.development.js:24645:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
redirect-boundary.js:56 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at recoverFromConcurrentError (react-dom.development.js:24381:20)
at performSyncWorkOnRoot (react-dom.development.js:24645:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
not-found-boundary.js:22 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at recoverFromConcurrentError (react-dom.development.js:24381:20)
at performSyncWorkOnRoot (react-dom.development.js:24645:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
redirect-boundary.js:56 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at recoverFromConcurrentError (react-dom.development.js:24381:20)
at performSyncWorkOnRoot (react-dom.development.js:24645:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
not-found-boundary.js:22 Uncaught Error: Unknown element <[object Object]> in collection.
at $eb2240fc39a57fa5$export$bf788dd355e3a401.getFullNode (import.mjs:219:23)
at getFullNode.next ()
at $eb2240fc39a57fa5$export$bf788dd355e3a401.iterateCollection (import.mjs:175:26)
at iterateCollection.next ()
at [Symbol.iterator] (import.mjs:303:22)
at Generator.next ()
at new $05ca4cd7c4a5a999$export$863faf230ee2118a (import.mjs:87:18)
at eval (import.mjs:118:159)
at eval (import.mjs:330:16)
at mountMemo (react-dom.development.js:12349:5)
at Object.useMemo (react-dom.development.js:13047:16)
at useMemo (react.development.js:1771:21)
at $7613b1592d41b092$export$6cd28814d92fa9c9 (import.mjs:324:65)
at $875d6693e12af071$export$728d6ba534403756 (import.mjs:118:90)
at useMenu (chunk-R4ZQ5Y3Q.mjs:47:87)
at Menu (chunk-B24OILC2.mjs:36:67)
at renderWithHooks (react-dom.development.js:10930:18)
at updateForwardRef (react-dom.development.js:15574:20)
at beginWork$1 (react-dom.development.js:18317:16)
at beginWork (react-dom.development.js:26647:14)
at performUnitOfWork (react-dom.development.js:25493:12)
at workLoopSync (react-dom.development.js:25209:5)
at renderRootSync (react-dom.development.js:25164:7)
at recoverFromConcurrentError (react-dom.development.js:24381:20)
at performSyncWorkOnRoot (react-dom.development.js:24645:20)
at flushSyncWorkAcrossRoots_impl (react-dom.development.js:10195:13)
at flushSyncWorkOnAllRoots (react-dom.development.js:10155:3)
at processRootScheduleInMicrotask (react-dom.development.js:10300:3)
at eval (react-dom.development.js:10471:7)
app-index.js:33 The above error occurred in the  component:
at NotFoundErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/not-found-boundary.js:54:9)
at NotFoundBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/not-found-boundary.js:62:11)
at DevRootNotFoundBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/dev-root-not-found-boundary.js:32:11)
at ReactDevOverlay (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/react-dev-overlay/internal/ReactDevOverlay.js:66:9)
at HotReload (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/react-dev-overlay/hot-reloader-client.js:297:11)
at Router (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/app-router.js:158:11)
at ErrorBoundaryHandler (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/error-boundary.js:100:9)
at ErrorBoundary (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/error-boundary.js:130:11)
at AppRouter (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/components/app-router.js:441:13)
at ServerRoot (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/app-index.js:127:11)
at RSCComponent
at Root (webpack-internal:///(app-pages-browser)/./node_modules/next/dist/client/app-index.js:143:11)

React will try to recreate this component tree from scratch using the error boundary you provided, ReactDevOverlay.
window.console.error @ app-index.js:33
Show 1 more frame
Show less
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue
copy code provided here: https://nextui.org/docs/components/navbar (Navbar with dropdown)
then try the component
Expected behavior
the dropdown menu should open
Screenshots or Videos
No response
Operating System Version
Windows 10
Browser
Chrome

NOTE: i tried to add "use client" and it works, is this component client only?

I have the same question. Shouldn't the menu be server-compatible? This is where some of the most important links going to be which require SSR.


Hocon impl

Please make sure these boxes are checked, before submitting a new PR.

[x] You ran rustfmt on the code base before submitting (on latest nightly with rustfmt support)
[x] You reference which issue is being closed in the PR text (if applicable)

Other Changes
Added test config for integration tests.
Added hocon configuration alternative for paxos and ble components.

I did not create a configuration file for ble and paxos in the tests as I was not sure if I should create different hocon configurations for each component as we provide the pid through the hocon configuration.
There are also some parameters for ble and paxos that can not be passed in a hocon configuration.


Fix arp requests in gatway operator

Description
The fix provides a way to route traffic between network namespace without the need of ARP requests hence decreasing the latency for new inter-cluster connections.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[x] Existing Unit and E2E tests

/test

/test

/merge


Add default value for marked for deletion flag

Describe this PR
What is the problem we're trying to solve
Marked for deletion flag doesn't have default value which means all records get filtered out by APIs.
What changes have we introduced
Set default value to false so the API returns correct records.
Checklist

[x] Code pipeline builds correctly

Follow up actions after merging PR
Run the alter table scripts in the PR

Will setting it default mean all current values will be false? By that I mean do we have to set as default and then run an update statement to set current ones to false?

@chubberlisk You are correct, update statements are also required. I have pushed an update to add those.

@chubberlisk I've pushed the manual update plan to this same PR for simplicity


Help URLs now open in the default browser

Fixes #767

I have to do some more work to double check, but at the present time, it doesn't seem to work on https://github.com/microbit-drill/epxt
The most important is that MS's electron encapsulation works.

oops: it is not committed: I apologise and await the commit


feat: set reprompt threshold in model settings

:tada: This PR is included in version 0.330.0 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


${DailySpecials(conversation.day_choice)} doesn't work

[Enter feedback here]
The syntax "- ${DailySpecials(conversation.day_choice)}" cannot be recognized, the response will just take the default.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 65c68413-d758-f0d4-1253-fe9730dd0bc9
Version Independent ID: 84b17640-22e3-130c-3233-d4af05b5b302
Content: Use Bot Framework Composer to display an options list in chatbots - Power Virtual Agents
Content Source: power-virtual-agents/advanced-bot-framework-composer-example2.md
Service: power-virtual-agents
GitHub Login: @iaanw
Microsoft Alias: iawilt

@ZuoXuangn The example currently appears to work as intended. Did you add the DailySpecials template to the bot responses tab? If you're still having trouble, can you share a screenshot of the error you're seeing?

Closing due to inactivity. @ZuoXuangn feel free to reopen if your problem persists.


account for src_nodata kwarg in xr_reproject

Passing in src_nodata as kwarg in odc.reproject raises a TypeError.
Example:
import xarray as xr
from numpy.random import uniform
from odc.geo.data import country_geom
from odc.geo.xr import rasterize

# Make some sample images
def gen_sample(iso3, crs="epsg:3857", res=60_000, vmin=0, vmax=1000):
    xx = rasterize(country_geom(iso3, crs), res)
    return xr.where(xx, uniform(vmin, vmax, size=xx.shape), float("nan")).astype("float32")

aus = gen_sample("AUS")
aus.odc.reproject(aus.odc.geobox.zoom_out(1), src_nodata=0)

Result:

TypeError: rio_reproject() got multiple values for keyword argument 'src_nodata'

The changes in this PR account for the kwarg, and give it precedence with the assumption the user wants to manually override it.

it's meant to come from nodata attribute of the source array, but sure, having an override can be useful sometimes.

it's meant to come from nodata attribute of the source array, but sure, having an override can be useful sometimes.

Like when source is missing nodata attribute, or has an incorrect one. Happens ...


About BHPA Mobile Responsive Design

Mobile Responsive site design for About BHPA page.
Figma frame link: https://www.figma.com/file/KbNIbEz1n8R5EVXEQLRSEX/Heat-Pump?node-id=2107-12740&t=IL6Sgo9OwtxHGdBU-0

Done @thiagobardini
Review: https://www.figma.com/file/KbNIbEz1n8R5EVXEQLRSEX/Heat-Pump?node-id=2107-12740&t=HH786kTIiN2hyYmy-0 (Mobile Responsive)


POST body are empty

I am not getting data of post body ?
neither req.all() gets nor req.post().
adonis-middleware/providers/AppMiddlewareProvider is in providers.
Also body parser is enabled as global middleware ..
i have disabled shield middleware do this will impact?

What is adonis-middleware/providers/AppMiddlewareProvider ?
and can you share the code of controller, where you are using req.all() ?

This is my routing file
'use strict';
module.exports = function(api) {
    api.group('apis', () => {
        api.post('/register', 'UserController.register');
        api.post('/login', 'UserController.login');
    }).prefix('/api');
}

And its my register method of UserController
*register (req,res){
    	const rules =  {
    		email : 'required|email',
    		password : 'required|min:6'
    	}

    	console.log(req.hasBody())
    	console.log(req.all())
    	const validation = yield Validator.validate(rules,req.post());
    	if(validation.fails()){
    		return req.error(req.formatedValidation(validation.messages()));
    	}
    	//if success
    }

It looks fine to me. May i know how you are sending the post data? If it is using postman, then a screenshot will be great.
And please do share the output of req.hasBody() and req.all().


Could trace-agent feasibly run as a K8S deployment to improve resource efficiency?

One of the challenges of running trace-agent container as part of the K8S DaemonSet is that some workloads generate a lot more trace data than others. These workloads are distributed unevenly across K8S workers, so as a result the trace-agent container on some workers have very high CPU and memory usage, while others have very low. As a result, we have to set CPU and memory limits very high for the trace-agent container to avoid OOM, which can lead to wasted CPU/memory resources on workers that aren't processing lots of trace data.
I don't know enough about how the trace-agent works, so my question is just about the feasibility of making trace-agent a deployment with pods that can process traces from any node. Feasibility aside, this would lead to more efficient use of resources. I do see a reference here to creating a headless Service for to process traces, so based on that I think it should be possible for trace-agents to process traces from other hosts. I know that many trace clients also generate DogStatsD metrics -- I don't know whether it's OK/safe to have those be sent to a different host than the client.

Hey @maxenglander
It is possible, but this would have some side effects that would basically remove some APM mechanisms.
The current mechanism is that application containers will send traces to the agent on the same node.
This adds the right host tags and container tags to the traces (thanks to the local kubelet), as well as linking the traces to the trace metrics.
If you have a trace-agent living on another node, receive the trace, you will lose this cardinality which will impact a lot the APM UI because the linked Infra metrics and container metrics will either wrong or not visible.
It also reduces troubleshooting abilities from support :) because we will not able to link the trace back to one host in particular.
Simon - Datadog Support Engineer

Makes sense @Simwar thanks for the reply


[AAP-22421] - public ping endpoint for http healthchecks

Please see:  https://issues.redhat.com/browse/AAP-22421 and https://issues.redhat.com/browse/AAPRFE-1202

we need to expose this view in a public path, /ping/, (right now is only available in /_healthz) Also I think it is a good opportunity to improve it adding a basic check of the database connection.
    try:
        connection.ensure_connection()
    except OperationalError:
        return HttpResponse("Database connection failed", status=500)

okay, got it!


Editor-Sidebar is vanishing for smaller screens

Hey there!
When trying to write/edit a post or a page on a smaller screen (like smartphone or tablet), the sidebar just disappears! Using pictures or setting tags is therefore nearly impossible.
I'm talking about THIS sidebar ;)

There is a CSS directive for the default-admin-theme, which just hides it for screen-sizes between (min-width: 333px) and (max-width: 959px):

./bl-kernel/admin/themes/default/css/default.css -- Line: 115

	.uk-width-large-2-10 { 		width: 0% !important; 		display: none !important; 	}
My question is: Why is this even in there? Deleting the whole directive brings back the sidebar (below the editor).
Max

Diego probably had some plans to make it more mobile friendly and put that there. I noticed this too but God bless the "Request desktop site" button on mobile browsers.

@acrox999 said:
Diego probably had some plans to make it more mobile friendly and put that there.

It works pretty well if you change the css in /bl-kernel/admin/themes/default/css/default.css as stated above. I think a PR could be submitted to make this small change or we could make a little adjustment.

Woops o.O
Sorry for the reference-mess in here. I tried to use the web-frontend for this little PR, since I'm at an other persons PC right now ... never again.
I'll provide a clean PR later.


[google_maps_flutter] Allow (de-)serialization of CameraPosition

Description
Make CameraPosition.toMap public and change visibility of CameraPosition fromMap.
Intended use:
              final s = json.encode(lastPosition.toMap());
              prefs.setString('cameraPosition', s);
...
              final map = json.decode(prefs.get('cameraPosition'));
              final cam = CameraPosition.fromMap(map);
              await controller.moveCamera(CameraUpdate.newCameraPosition(cam));

Related Issues
Fixes https://github.com/flutter/flutter/issues/34321
Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[ ] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
Presumably none needed
[ ] All existing and new tests are passing.
Impossible: https://github.com/flutter/flutter/issues/33964
[ ] I updated/added relevant documentation (doc comments with ///).
None found
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the [Flutter Style Guide].
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[] I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].
Pending review
[ ] I updated CHANGELOG.md to add a description of the change.
Pending review
[x] I signed the [CLA].
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Change looks good. Can you update the pubspec and changelog? Thanks!

@duzenko I was busy with some issues in the past couple of weeks. Let me know if you get a change to fix the merge conflicts and we can merge this.

@iskakaushik
I'm traveling and AFK most of the time. I'll try to do some time.

@duzenko I was busy with some issues in the past couple of weeks. Let me know if you get a change to fix the merge conflicts and we can merge this.

Fixed

Now that marker drag events is in. Can you please rebase?

Now that marker drag events is in. Can you please rebase?

Done.
What about my other PRs - #1719 & #1821?

@duzenko I'm trying to figure out what is wrong with the plugin tools format to drive https://github.com/flutter/plugins/pull/1821 to green and get it merged. For the other PR it will get prioritized per the number of thumbs-up in the issues.


Allow to specify libmagma path via preferences

This PR adds support for a libmagma preference that can be used to explicitly specify a path to a local libmagma library (as an alternative to using the one provided via MAGMA_jll). The default doesn't change, that is, MAGMA_jll is used if no preference is specified.
Also, a MAGMA_jll.is_available() check is added. If it fails, e.g. when there is no product available for the host platform, a warning is thrown and libmagma is just set to "libmagma" (assuming that a local libmagma is dynamically loadable).

thank you for doing this


Multiple summary files are not supported contrary to what documentation states

The page says
Multiple summary files will be merged into a single report.
However, when I use minimatch pattern and it finds multiple files it ends up with error:
##[warning]Multiple file or directory matches were found. Using the first match: /agent/_work/3/s/repo-name/submodule-name/build/reports/jacoco/test/jacocoTestReport.xml

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c6ac4ff4-9839-6a6d-8d20-a25084d221ef
Version Independent ID: bd09f139-8e69-8ea1-6671-b7bba8e17c23
Content: Publish Code Coverage Results task - Azure Pipelines
Content Source: docs/pipelines/tasks/test/publish-code-coverage-results.md
Product: devops
Technology: devops-cicd-tasks
GitHub Login: @shashban
Microsoft Alias: shashban

@shashban Thanks for your question. While we look into it, consider these resources:

Azure DevOps Services
Azure DevOps Support Bot
Azure DevOps on Stack Overflow


behavior_path_planner do not consistently expand the drivable area

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I'm convinced that this is not my fault but a bug.

Description
The behavior_path_planner generates the drivable area which can be expanded to the left or right using the following parameters.
https://github.com/autowarefoundation/autoware.universe/blob/a4078bdf374fc617f5be531e50e892aefbbc53e0/launch/tier4_planning_launch/config/scenario_planning/lane_driving/behavior_planning/behavior_path_planner/lane_following/lane_following.param.yaml#L4-L6
This functionality works most of the time but there are situations when the drivable area is not expanded.
Expected behavior
The drivable area is always expanded.
Actual behavior
The drivable area is not expanded when an obstacle is near the ego path.
Steps to reproduce
1 - Update parameters to expand the drivable area.
2  - Plan a path and observe the drivable area in rviz.
- Type: DrivableArea
- Topic: /planning/scenario_planning/lane_driving/behavior_planning/path
- Recommended color scheme: costmap.
3 - Add an obstacle near the path and observe the drivable area no longer being expanded.
https://user-images.githubusercontent.com/48479081/188827600-4590d028-34fd-4d2f-9db0-58f80b161c5b.mp4
Versions
No response
Possible causes
https://github.com/autowarefoundation/autoware.universe/issues/1759#issuecomment-1240550714

Static expansion of drivable area is only implemented in lane_following for now.
By implementing it in other modules, you can use the static expansion in any module.

Additional context
No response

I will make a PR this week.


Roll Engine from af6889a600e7 to<PHONE_NUMBER>c5 (6 revisions)

https://github.com/flutter/engine/compare/af6889a600e7...7252263702c5
2020-12-21<EMAIL_ADDRESS>format forked chromium accessibility code
2020-12-21<EMAIL_ADDRESS>fork additional raw chromium a11y code
2020-12-21<EMAIL_ADDRESS>Update ios to use new YUVA texture SkImage factory (flutter/engine#23153)
2020-12-21<EMAIL_ADDRESS>Roll Skia from 6aea07880248 to e42716032b4b (1 revision) (flutter/engine#23216)
2020-12-21<EMAIL_ADDRESS>Re-merge Switch web-render option default to auto. Add documentation (flutter/engine#23187)
2020-12-21<EMAIL_ADDRESS>Roll Skia from 88883c4ca259 to 6aea07880248 (1 revision) (flutter/engine#23213)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Gold has detected about 24 untriaged digest(s) on patchset 6.
View them at https://flutter-gold.skia.org/cl/github/72769

Commit queue failed; closing this roll.


ci: add test for wasm32-wasi

Plan to add tests for wasm32-wasi using wasmer

Close and reopen to trigger CI check.

why wasmer is not found on rerunning?


AWS not working when sending test to litmus.

Whenever I add an image to an email, and push to litmus, I get the following error on the AWS task:
[15:39:38] 'aws' errored after 1.63 s
[15:39:38] 503: null
at Request.extractError (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/services/s3.js:577:35)
at Request.callListeners (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
at Request.emit (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
at Request.emit (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:683:14)
at Request.transition (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:22:10)
at AcceptorStateMachine.runTo (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request. (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:38:9)
at Request. (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:685:12)
at Request.callListeners (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
at Request.emit (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
at Request.emit (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:683:14)
at Request.transition (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:22:10)
at AcceptorStateMachine.runTo (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request. (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:38:9)
at Request. (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/request.js:685:12)
at Request.callListeners (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/sequential_executor.js:115:18)
at callNextListener (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/sequential_executor.js:95:12)
at IncomingMessage.onEnd (/Users/mattowens/Desktop/SCT/node_modules/gulp-awspublish/node_modules/aws-sdk/lib/event_listeners.js:269:13)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
I have gone back to all my previously developed emails that worked fine, and am now getting the same error.
Anyone else experiencing this?

And all of a sudden it looks like it is working again.  Weird.


Randomization between two pieces of content

As an ADMIN I would like to be able to send users randomly to Content A or Content B. I might use this for:

A/B testing of content, with success depending on a feedback survey or user quiz scores
Breaking very long surveys down into smaller parts which are randomly distributed to respondents - all questions get answers, but nobody has to fill out the complete very long survey

Minimum requirements:

Randomization is spread evenly among several possibilities
Option for the randomized element to have a fixed text

For example, if the randomized element is a Page Button, the Page Button should be able to have a fixed text even if the random destinations have different title texts

What I don't believe matters right now:

Whether the randomization happens as the page is built (random URL is inserted into HTML) or it happens on click (a set URL directs to a random destination)
What specific function we add this to - I could see the randomization possibly happening in a Page Button, Page Link Page, possibly other places
We don't need to have a dynamic number of random possibilities if that makes this difficult from a UI standpoint, we have the option to set 10 random possibilities and the user populates 5x the first page and 5x the second page if there are only two pages to randomize
This doesn't have to be set up in Wagtail, this could also be an nginx solution if that is simpler

@ChrisMarsh82 Could the team please think about what the easiest way to do this would be? This may be needed for the Turkiye/Syria response

Breaking very long surveys down into smaller parts which are randomly distributed to respondents - all questions get answers, but nobody has to fill out the complete very long survey

What does “smaller parts means”? Different surveys/quizzes or a divider in a single survey/quiz? Latter is not only complicated but complex.

Whether the randomization happens as the page is built (random URL is inserted into HTML) or it happens on click (a set URL directs to a random destination)

The first option is good, pick a random option while building the page as redirection could be slow.

What specific function we add this to - I could see the randomization possibly happening in a Page Button, Page Link Page, possibly other places

We can create a new block similar to the page button where one can add choices of one type to serve from.

This doesn't have to be set up in Wagtail, this could also be an nginx solution if that is simpler

Not sure about this.

By smaller survey parts I mean separate Pages on Wagtail, I also thought the latter sounded complex and not worth the extra effort.
Random URL inserted into HTML sounds good.
Page Button block is fine for now.

@cbunicef Can you tell me which pages will access this Random Page Button Block?

@Alihassanc5
Can we please add the Random Page Button block to all the places where there are Page Buttons right now?
Admin can add different types of Pages

The current solution will not work with page caching because any page that features the 'random page' button is very likely to be cached and that means that the randomization will only happen once before the page is cached, and subsequently only if the cache expires or is flushed.
If this needs to turned around very quickly, for a specific use case, there is a solution involving nginx that we could try. If this feature is still desired after the initial use case, we'll have to think of a different solution that works with and without page caching.
@cbunicef Let us know your thoughts.

@istride Let's go ahead with the nginx solution for now. I will add info to DevOps that I think you might need. The survey launches at the start of next week, but I will set the office's expectation that we are finishing the randomization ASAP.


Red Hat and derivatives are not fully supported, but we take patches.

Hello!
This is from the docs. Could you please elaborate? I'd like to understand what won't work on RHEL and derivatives.
Thanks!

I've removed RHEL support in the readme and metadata.  It's not fully functional.  There are several outstanding pull requests to better support RHEL systems, but they need to be rebased and the authors have yet to sign the required iCLA doc.


Suggestion: add a compatibility with Tidal

please yesss

Please add compatibility for tidal!

WebNowPlaying does support Tidal inside your web browser, but sadly the desktop app can not be supported because there is no specific Rainmeter plugin made for it yet.
If someone decided to make a plugin for Rainmeter, we can add it but for now it's not possible.


Proposal: argo logs workflow-xxx

Perhaps it would be useful if argo logs workflow-xxx cat'ed all the logs for the sub steps.

I'm wondering if this is another problem that would be solved by having K8s provide good support for tagging and fetching logs using pod labels. (This is a big issue for Kubeflow). We have the same problem for TFJobs where we have multiple pods and people want to see the logs for specific pods or all pods.
My general sense is that this should be solved by having all logs tagged with the pod labels. Then CRDs just need to attach appropriate pod labels. So for Argo it could be the workflow name, step name etc..., for TFJob it would be job name, replica index, etc...
Then a user could just fetch the logs by querying by pod label either via CLI or by whatever mechanism the backend supports (e.g. stackdriver UI).
From what I gather from the logging folks, this will be done by using side cars in the pod to attach pod labels to logs before shipping them out.

Feature had been implemented. Workflows logs can be accessed using -w flag: argo logs -w <workflowName>


Link back to purify package

For people who have never seen it before

Oh. Obviously missed out on that really good for a very long time. :)
Thanks! Will merge.


Invalid 'main' field problem

What version of Turborepo are you using?
1.6.3
What package manager are you using / does the bug impact?
npm, Yarn v1
What operating system are you using?
Windows
Describe the Bug
Hi, I have a problem with my turbo project. I have express application under apps folder and several packages under packages folder. I'm using the Typescript.
Problem arises when I'm trying to run the project in the Docker container.
For example, I have db package, in package.json of this package I have these lines:
  "main": "./index.ts",
  "source": "./index.ts",
  "types": "./index.ts",

During the development everythig is fine, but if I build my project with Dockerfile and run it, I receive an error
/app/packages/db/index.ts:1
export {
^^^^^^

SyntaxError: Unexpected token 'export'

This is because main property in package.json is index.ts (I have compiled version under /dist folder, but it is not used, because of this property).
So, to make it work, I assume, that I need to change main property to /dist/index.js (so that node runtime can handle it), but if I do so, I cannot run my project in development mode. Now error is
backend:dev: DeprecationWarning: Invalid 'main' field in '<full path here>\db\package.json' of './dist/index.js'. Please either fix that or report it to the module author
backend:dev:     at tryPackage (node:internal/modules/cjs/loader:447:15)
backend:dev:     at Module._findPath (node:internal/modules/cjs/loader:678:18)
backend:dev:     at Module._resolveFilename (node:internal/modules/cjs/loader:1061:27)
...

I have tried project from turbo examples, but got the same error.
Expected Behavior
It should work both in development mode and in production mode.
To Reproduce
To reproduce, you can get with-docker example and run npm run dev
Reproduction Repo
https://github.com/vercel/turbo/tree/main/examples/with-docker

I made temporary fix, by adding small node script, which rewrites package.json before run:
const { readFileSync, writeFileSync } = require("fs");

var args = process.argv.slice(2);
const path = args[0];

const packageJson = readFileSync(path, "utf8");
const obj = JSON.parse(packageJson);

obj["main"] = "./dist/index.js";
obj["module"] = "./dist/index.mjs";
obj["types"] = "./dist/index.d.ts";

writeFileSync(path, JSON.stringify(obj), "utf8");

In  my Docker file I added two lines:
COPY rewriteConfig.js rewriteConfig.js
RUN node ./rewriteConfig.js /app/packages/db/package.json

Hi, thanks for the answer! But your example does not work out of the box now, maybe it should be fixed, to avoid the same issues in the future.

for me this is happening without docker as well

for me this is happening without docker as well

the apps and packages folder end up in the dist folder of the application under apps

The original issue sounds like a userland issue.
On examples, we've updated them recently. Please open an issue if you have any problems with them!


fix(install): Fix generated TOC styling

Summary
Allow core installation docs to use the Table of Contents extension
Full changelog

Adds call to toc.html in install page layout, moves it out of main content section to ensure it displays correctly
Updates all installation pages to use the new TOC

Issues resolved
Fix #917

One thing to note:
Kubernetes TOC changes from

to

That seems intentional and consistent, approving.


Perlmutter Error

I have a few tests failing on Perlmutter, Do you have any thoughts on the cause?  Can you share the slurm submission/job scripts?

@cwsmith this is the submission script:
salloc --time 00:10:00 --constraint=gpu --qos=interactive --nodes=1 --ntasks-per-node=40 --cpus-per-task=1 --gpus=1 --account=m4564

Hmmm.  Can you try increasing to 4 gpus for the allocation?

@cwsmith
When I increase to 4 gpus all of the tests fail with this error:
terminate called after throwing an instance of 'std::ios_base::failure[abi:cxx11]'
  what():  [Wed Aug  7 11:53:34 2024] [ADIOS2 EXCEPTION] <Engine> <BP4Reader> <OpenFiles> : File meshVtxIds_c2s.bp could not be found within the 60.000000s timeout

Hm. Do you think perlmutter could be caching that file and it's not hitting the filesystem?

I found that the second srun command was not running because the first one was eating all of the resources. After I modified the srun command the original bug started appearing again.

if you do bpls on the .bp file does the _srcRanks variable exist?

This is my output from running that command:
castia5@login34:test$ bpls meshVtxIds_c2s.bp/
  int32_t  redev client communicator size  scalar
castia5@login34:test$ bpls meshVtxIds_s2c.bp/
  int32_t   class partition ents and ranks  [1]*{756}
  string    redev git hash                  scalar
  uint64_t  redev partition type            scalar
  int32_t   redev server communicator size  scalar

What about for the s2c file?
Also, looking at the error that should have a name associated with it: https://github.com/SCOREC/redev/blob/f4b1d75b6996f5ed0a7c87c25f9d146d22babc80/redev_comm.h#L231

After a debugging meeting with Jacob, he found the cause of one of the bugs and one of the tests is now passing. It seems that one of the other tests is probably failing for the same reason. I still need to investigate the third test.
The issue was that before communication using redev; a communication phase needs to be started and ended.


Use BrainLocationShape in PatchedSlice schema

Replace the property shape 'brainRegion' by the property shape 'brainLocation' in PatchedSlice schema

Was fixed with #189


WIP: Port redis-py impl and tests to aioredis.

What do these changes do?
This is a full port of redis-py's client implementation into an asyncio-friendly implementation.
The approach is essentially a line-by-line re-implementation. The major caveats to this are:

Some connection code is simply incompatible and had to be implemented differently.
We use black on our code-base, which will create line-count discrepancies between the two sources.
I've added a first-pass at type annotations (a lot of work is needed to tighten it up if we want to add mypy to our CI, but it gets us much further along).

Beyond that, all functional logic remains as close to the original, synchronous source as possible.
The motivation behind this is to ease the workload for future contributors and maintainers. By replicating redis-py's implementation, we greatly reduce our own workload, and are able to quickly port new features and bugfixes as they are added to redis-py, including tests.

Are there changes in behavior for the user?
Yes.

Related issue number
#822
Checklist

[x] I think the code is well written
[x] Unit tests for the changes exist
[ ] Documentation reflects the changes
[ ] If you provide code modification, please add yourself to CONTRIBUTORS.txt

The format is <Name> <Surname>.
Please keep alphabetical order, the file is sorted by names.

[ ] Add a new news fragment into the CHANGES/ folder

name it <issue_id>.<type> (e.g. 588.bugfix)
if you don't have an issue_id change it to the pr id after creating the PR
ensure type is one of the following:

.feature: Signifying a new feature.
.bugfix: Signifying a bug fix.
.doc: Signifying a documentation improvement.
.removal: Signifying a deprecation or removal of public API.
.misc: A ticket has been closed, but it is not of interest to users.

Make sure to use full sentences with correct case and punctuation, for example:
Fix issue with non-ascii contents in doctest text files.

@Andrew-Chen-Wang as promised... this is the port from redis-py.
I still need to investigate some intermittent test failures but this is mostly complete.

@Andrew-Chen-Wang as promised... this is the port from redis-py.
I still need to investigate some intermittent test failures but this is mostly complete.

woah this is super cool. I skimmed through the code today and I'll review it later this weekend. I'm a little afraid though that there'll be a lot of breaking changes...? But this is awesome!!!
Additionally, we probably would want to run a benchmark of the port vs. v1.3.1 if there's any significant change (I assume not much since the structure is really pretty much the same). Also note: there are a couple remnants of redis-py in some places like L3827 aioredis/client.py and I'm assuming tested Redis version is v5 for now (i.e. the auth still only allows password)?

woah this is super cool. I skimmed through the code today and I'll review it later this weekend. I'm a little afraid though that there'll be a lot of breaking changes...? But this is awesome!!!
Additionally, we probably would want to run a benchmark of the port vs. v1.3.1 if there's any significant change (I assume not much since the structure is really pretty much the same). Also note: there are a couple remnants of redis-py in some places like L3827 aioredis/client.py and I'm assuming tested Redis version is v5 for now (i.e. the auth still only allows password)?

My biggest concern is this is completely untested in production, and pretty different from the existing aioredis lib. I'm wondering if we should push out a beta version of the current status of the repo, or we should instead just implement this PR and push it out. It'll have a lot of breaking changes, and a lot of people aren't fans of migrations.

My biggest concern is this is completely untested in production, and pretty different from the existing aioredis lib. I'm wondering if we should push out a beta version of the current status of the repo, or we should instead just implement this PR and push it out. It'll have a lot of breaking changes, and a lot of people aren't fans of migrations.

Yeah - I think it’s a valid concern, however we also get the benefit that it’s now much easier for current users of redis-py to migrate their existing code to aioredis, which may help drive adoption and in turn drive community support.
As long as we have a decent alpha/beta/rc period and good migration docs, I think this could be the way to go.
As for breaking changes or the outstanding changes we currently have in master… many of the changes or bug fixes are moot with this PR, and many outstanding features (such as full support for redis 6) are now done. Additionally, master currently contains breaking changes of its own, so I don’t see value in pushing out a beta there if we go this route.
All in all, my main goal in maintaining this library is to make continued maintenance as easy as possible. The loss of the core maintainer of this library exposed a very real problem that happens to codebases with a large amount of custom code and only one author - there is little understanding of the original implementation or the motivations behind it. Such code is always at a high risk of “aging” to a state where no one can touch it or make effective contributions.
I don’t want to see that happen again, and I think the best way to do that is ensure that the code itself can be understood by as many people as possible.
Does that make sense?

Yeah - I think it’s a valid concern, however we also get the benefit that it’s now much easier for current users of redis-py to migrate their existing code to aioredis, which may help drive adoption and in turn drive community support.
As long as we have a decent alpha/beta/rc period and good migration docs, I think this could be the way to go.
As for breaking changes or the outstanding changes we currently have in master… many of the changes or bug fixes are moot with this PR, and many outstanding features (such as full support for redis 6) are now done. Additionally, master currently contains breaking changes of its own, so I don’t see value in pushing out a beta there if we go this route.
All in all, my main goal in maintaining this library is to make continued maintenance as easy as possible. The loss of the core maintainer of this library exposed a very real problem that happens to codebases with a large amount of custom code and only one author - there is little understanding of the original implementation or the motivations behind it. Such code is always at a high risk of “aging” to a state where no one can touch it or make effective contributions.
I don’t want to see that happen again, and I think the best way to do that is ensure that the code itself can be understood by as many people as possible.
Does that make sense?

Was there a reason you needed to add redis-server --daemonize yes in d9cbb9b?

Was there a reason you needed to add redis-server --daemonize yes in d9cbb9b?

Was there a reason you needed to add redis-server --daemonize yes in d9cbb9b?

Yeah - aioredis has traditionally started all of its own redis-servers internally within the test run. I've been trying to move away from that and instead run the redis as external processes and break out each redis version we test as its own test run.

Was there a reason you needed to add redis-server --daemonize yes in d9cbb9b?

Yeah - aioredis has traditionally started all of its own redis-servers internally within the test run. I've been trying to move away from that and instead run the redis as external processes and break out each redis version we test as its own test run.

So Windows tests are still borked, but I'm wondering if they're of any value considering we're running the tests on a pretty old version of Redis to begin will.
I may mark these as allowed to fail and look at putting Windows on Azure pipelines in the near future.

So Windows tests are still borked, but I'm wondering if they're of any value considering we're running the tests on a pretty old version of Redis to begin will.
I may mark these as allowed to fail and look at putting Windows on Azure pipelines in the near future.

Hm I'm still of the opinion most devs aren't even using Redis at this point if they're on Windows; if they were, they would already be using WSL, which would mean they're using the latest version of Redis. At least to me, it feels like unnecessary maintenance and not really worth the effort to test for the lower versions anyways (e.g. redis-py, aredis, and asyncio-redis don't test them).

Hm I'm still of the opinion most devs aren't even using Redis at this point if they're on Windows; if they were, they would already be using WSL, which would mean they're using the latest version of Redis. At least to me, it feels like unnecessary maintenance and not really worth the effort to test for the lower versions anyways (e.g. redis-py, aredis, and asyncio-redis don't test them).

Aaaand our tests are green! ✅
I'm going to dig into making sure we're exporting our codecov correctly, then update documentation to reflect this major change.

Aaaand our tests are green! ✅
I'm going to dig into making sure we're exporting our codecov correctly, then update documentation to reflect this major change.

OMG, what it has become((((

OMG, what it has become((((

If and when this is merged fill free to rename the library into redis-py-asyncio, its just not aioredis any more... (((

If and when this is merged fill free to rename the library into redis-py-asyncio, its just not aioredis any more... (((

Now, without a sarcasm.
This is not the way to go!
You literally deleted all aioredis code and cloned redis-py. This library is not a port of something else!
This is not proper place to make redis-py asynchronous, you should have had open this PR in that repository.

Not buffering responses from redis into a byte-stream (as redis-py does). Instead we wrap our futures with deserialization futures, which is hard to debug and leads to ambiguous low-level asyncio errors. Buffering reads into a byte-stream means we can write more discernible and understandable code for our parsing, which now doesn't need to deal with futures directly.

Why not refactoring connection logic to use asyncio protocol not streams?

Making the ConnectionPool and Connection objects interchangeable on a single attribute. For simple cases, this makes sense, but for many cases the ambiguity results in potentially bad or unexpected behavior.

I disagree. First of all, there always was a way to explicitly acquire a connection to use it, there should be documentation and examples how to do it. And AFAIR the case is opposite: this works for most cases.

The codebase is littered with TODOs acknowledging areas where we need to go back and "pin" a connection to prevent unexpected behavior. A much better pattern here would be to have an explicit connection attribute and always explicitly aquire a connection if necessary.

Partially agree. This how it worked in the very beginning. Agree that connections handling need refactoring but I believe that bringing new ideas can be better than copy-pasting someone else's code.

Porting from redis-py also lowers the barrier to implementing new features as Redis advances, as we're now able to source potential solutions from another library.

"implementing" here is just a wrong word, "copying" is the one.

All the motivation above looks to me like a reluctance to improve and evolve current aioredis library, this makes me really sad.
Under the hood aioredis is not simple and a person who wants to develop/enhance must deeply understand how it works.

Now, without a sarcasm.
This is not the way to go!
You literally deleted all aioredis code and cloned redis-py. This library is not a port of something else!
This is not proper place to make redis-py asynchronous, you should have had open this PR in that repository.

Not buffering responses from redis into a byte-stream (as redis-py does). Instead we wrap our futures with deserialization futures, which is hard to debug and leads to ambiguous low-level asyncio errors. Buffering reads into a byte-stream means we can write more discernible and understandable code for our parsing, which now doesn't need to deal with futures directly.

Why not refactoring connection logic to use asyncio protocol not streams?

Making the ConnectionPool and Connection objects interchangeable on a single attribute. For simple cases, this makes sense, but for many cases the ambiguity results in potentially bad or unexpected behavior.

I disagree. First of all, there always was a way to explicitly acquire a connection to use it, there should be documentation and examples how to do it. And AFAIR the case is opposite: this works for most cases.

The codebase is littered with TODOs acknowledging areas where we need to go back and "pin" a connection to prevent unexpected behavior. A much better pattern here would be to have an explicit connection attribute and always explicitly aquire a connection if necessary.

Partially agree. This how it worked in the very beginning. Agree that connections handling need refactoring but I believe that bringing new ideas can be better than copy-pasting someone else's code.

Porting from redis-py also lowers the barrier to implementing new features as Redis advances, as we're now able to source potential solutions from another library.

"implementing" here is just a wrong word, "copying" is the one.

All the motivation above looks to me like a reluctance to improve and evolve current aioredis library, this makes me really sad.
Under the hood aioredis is not simple and a person who wants to develop/enhance must deeply understand how it works.

@popravich -
Welcome back! I'm glad you've returned.
I want to be clear from the start: if you wish to resume maintenance of this library, then I will of course retract this PR and step away. I made it clear in #822 that I was taking this position on in a temporary manner in order to get contributions flowing again.
This PR is an attempt to make this library maintainable by more than just a single author. Porting redis-py achieves that goal. It is a pragmatic choice. I don't particularly like all of the decisions in that library, but I do think that using redis-py as an original source means there doesn't have to be a single BDFL maintaining this library, which has been my goal since taking on temporary maintainership. When I made this decision, the original author hadn't been heard from in over a year.
Faced with that knowledge, I made the choice to do what you see here today. With this change, continuing contributions to this code-base are much simpler. The redis-py implementation is not only well understood, it is also officially endorsed by Redis. The aioredis implementation is not well understood by anyone but you. I would say I'm quite familiar with it as well at this point, but that is not an argument for keeping said implementation. That should be a warning sign. When the barrier to maintainership is so high, and the pool of individuals with enough understanding to provide meaningful contributions to its core is so low, that is a signal that the library is doomed to die. And we have proof of that right here.
I don't wish to "kill" others' contributions, but your argument is a sunk cost fallacy. The fact that prior effort and time has been put into a project should not prevent one from changing course when situations change. And they did, drastically.
I do not think the original code was "bad". I actually quite like a lot of it. But that's not why I went this direction and I hope you understand that.
Again, I'll re-iterate, if you wish to resume maintenance and see nothing of value in these changes, then that's fine. I won't fight you simply because I put in the work. You are the original author of this library and I respect that, but I hope you'll understand my reasoning.

@popravich -
Welcome back! I'm glad you've returned.
I want to be clear from the start: if you wish to resume maintenance of this library, then I will of course retract this PR and step away. I made it clear in #822 that I was taking this position on in a temporary manner in order to get contributions flowing again.
This PR is an attempt to make this library maintainable by more than just a single author. Porting redis-py achieves that goal. It is a pragmatic choice. I don't particularly like all of the decisions in that library, but I do think that using redis-py as an original source means there doesn't have to be a single BDFL maintaining this library, which has been my goal since taking on temporary maintainership. When I made this decision, the original author hadn't been heard from in over a year.
Faced with that knowledge, I made the choice to do what you see here today. With this change, continuing contributions to this code-base are much simpler. The redis-py implementation is not only well understood, it is also officially endorsed by Redis. The aioredis implementation is not well understood by anyone but you. I would say I'm quite familiar with it as well at this point, but that is not an argument for keeping said implementation. That should be a warning sign. When the barrier to maintainership is so high, and the pool of individuals with enough understanding to provide meaningful contributions to its core is so low, that is a signal that the library is doomed to die. And we have proof of that right here.
I don't wish to "kill" others' contributions, but your argument is a sunk cost fallacy. The fact that prior effort and time has been put into a project should not prevent one from changing course when situations change. And they did, drastically.
I do not think the original code was "bad". I actually quite like a lot of it. But that's not why I went this direction and I hope you understand that.
Again, I'll re-iterate, if you wish to resume maintenance and see nothing of value in these changes, then that's fine. I won't fight you simply because I put in the work. You are the original author of this library and I respect that, but I hope you'll understand my reasoning.

This is awesome work @seandstewart!

Was there a reason you needed to add redis-server --daemonize yes in d9cbb9b?

Yeah - aioredis has traditionally started all of its own redis-servers internally within the test run. I've been trying to move away from that and instead run the redis as external processes and break out each redis version we test as its own test run.
It makes debugging test failures much simpler, since it's not one 10K line output per test run

I think you should consider using https://github.com/biocatchltd/yellowbox . It provides a simple wrapper for setting up and tearing containers between tests, and we already have a RedisService class that is easily extensible. This way the tests can run on any system with Docker.

I think the biggest problem with this fork is just the huge migration. I feel like taking advantage of the popularity of using aioredis was the point of keeping this as one package rather than converting it into a new package. There are still good portions of aioredis that can inspire some changes in this fork, but I have to agree that the maintainability is quite difficult.
I've used aioredis before for my own package and projects, and I try to help maintain this package, but, to be fair, I also have quite a bit of trouble understanding the code base.
There are a couple options:

Make aioredis a little easier to understand to maintain and forget about this fork. @popravich This may be biased, but can you point out how you think people could better understand this package besides documentation?
Make a new package based on this fork. Erases quite a bit of the popularity, and such adoption is limited and aioredis will probably never release with updates again if maintainer ship does not keep it moving.
Use the name of this package in favor of this fork. Adoption is quite clearly high, migration will be a slight pain, but easier maintainability and hopefully more useful PRs to fix any nagging portions.

In my opinion, I actually like option 1 if we can identify the pain points of this package (honestly, it's quite a bit like the acquire/release mechanism, magic methods of aenter etc.). But if we can't identify the pain points that basically causing us to not understand how we could fix those TODOs, then the next best option would be option 3.
Thoughts?

@Andrew-Chen-Wang -
Thanks for the thoughtful response here and sorry for the 5-day delay in responding back.
I'm obviously biased in my choice, I'd rather rip the band-aid off now (move forward with migrating this codebase) but I do see value in minimizing the changeset and erring on the side of caution. In most any other situation I'd agree to a more conservative approach.
I won't lie though, I really have limited time and won't be around with this frequency forever. My schedule and mental health won't sustain it. My concern with a smaller port is that there is still a barrier to entry for any new maintainer and a piecemeal port means a long-term investment that I'm not sure anyone currently contributing has in them. Maybe that's unfounded, but I'd like to err on the side of caution w.r.t. active maintainership. I know that if all we need to do for new features is watch redis-py for changes and port them over, there's a much much greater likelihood of keeping this library moving. The same can go for the parser logic and the implemented clients.
For connection-related bugs we'll still need to do triage, but thankfully the connections implementation in this PR is easier to grok than the original version so we've still got a win there.
I will defer (a bit) to the will of the community here, with a grain of salt. At the end of the day I want to make we do right by our community and I do think the best way to do that is to keep the codebase maintainable and up-to-date, so whatever we decide to do, let's just be sure we're achieving that goal.

Was there a reason you needed to add redis-server --daemonize yes in d9cbb9b?

Yeah - aioredis has traditionally started all of its own redis-servers internally within the test run. I've been trying to move away from that and instead run the redis as external processes and break out each redis version we test as its own test run.
It makes debugging test failures much simpler, since it's not one 10K line output per test run

I think you should consider using https://github.com/biocatchltd/yellowbox . It provides a simple wrapper for setting up and tearing containers between tests, and we already have a RedisService class that is easily extensible. This way the tests can run on any system with Docker.

Very nice! I think if/when this PR merges, we can look at what integrating this would mean for our testing.

Any news ?

Any news ?

Hey @aviramha - I wanted to wait a few days before moving forward, in the event folks from the community wanted to weigh in.
I'm also working on revamping the documentation and providing a migration guide so that when we land this change there's ample resources to support developers.

Any news ?

Hey @aviramha - I wanted to wait a few days before moving forward, in the event folks from the community wanted to weigh in.
I'm also working on revamping the documentation and providing a migration guide so that when we land this change there's ample resources to support developers.

Awesome, it's completely understood. I'm a bit paranoid the project will go stale again so was just pinging. If you need any help let me know.

I will share my thoughts in a day or two, too much complex work right now.

I will share my thoughts in a day or two, too much complex work right now.

Hey @popravich just wanted to check in. I respect that you have work and a life but I'd like to get your input before we move in any direction with this PR. I'd also like to avoid this project becoming stale again.

Ok guys, first of all thank you for your contribution to the project.
But I don't think this is the way to go for aioredis, especially when
there already is a redis-py port to asyncio — aredis.
I know that internals of aioredis is hard to understand and I acknowledge
that it must be revised, with current connections management design
(and some other parts) it gets hard to extend the library, especially
with new Redis 6 protocol.
In my opinion we should do the following. First, current issues need to be addressed
to differentiate simple issues/tasks that do not require internals hacking
and are straightforward to fix/implement and would lead library to 1.4 release.
Next, connection management should be redesigned to be ready for new
Redis features which should bring us to aioredis version 2.
I don't want you guys to step back I appreciate your work and I will
help you understand all those internals with TODOs and other stuff
so we can move aioredis to new major release.
I would like to keep nice aioredis features and also make easier to support and develop,
just not with a such a dramatic change.

I don't want you guys to step back I appreciate your work and I will
help you understand all those internals with TODOs and other stuff
so we can move aioredis to new major release.

I'm in favor of this, but I'm also limited on time with school and may need to step back on maintainership. HOWEVER:

But I don't think this is the way to go for aioredis, especially when
there already is a redis-py port to asyncio — aredis.

aredis is not exactly maintained. I looked around for async redis clients for awhile, and none of them were exactly maintained, so I stuck with aioredis simply because it had the most stars and I thought maintainership would resume under the aio organization. And it did!
Like the synchronous Redis-py lib, we could make aioredis the sole async redis client for the entire Python ecosystem because we 1. have maintainership resumed and 2. have a large community backing. Sorry if that sounds political/inorganic (in growth), but based on everyone's async benchmarks and a different issue where someone said aioredis is 3 times slower than redis-py but the speeds are the same using this port, I think going down this PR's path is also OK.
Yes alternatives are great, but performance and maintainership is key to every library, and none of them have the latter, including aioredis for a long time.

based on everyone's async benchmarks and a different issue where someone said aioredis is 3 times slower than redis-py

It is great that we have such benchmarks so it is possible to identify slow code, but I believe that pipeline/transaction issues can be fixed in terms of aioredis code maybe even reusing redis-py parts/ideas.

To give an aioredis users' perspective: It's no secret our community lacks a sustainable, updated, high quality, performant async redis library. I have to give kudos to @seandstewart as he has a sound plan which I for one believe is the quickest (and time may prove, the only sustainable) way to solve this.
I've been closely following and it's concerning our limited resources within the community may be wasted on a sunk cost problem- @popravich has done some amazing work over the years but aioredis' technical debt may be so high that we face a very real danger of project death as a rewrite is likely beyond the scope of what anyone here can sustainably contribute, even collectively. This is a worst case scenario for everyone involved.
The advantages of a redis-py port are very clear and will only get more advantageous as time moves forward, especially as current aioredis falls more behind.

Go on with this PR just rename the library and repository to aioredis-py so that difference and changes between aioredis and releation to redis-py is clear and honest. I realized that I would not have enough time to drive the development and it also makes me sad that no one wants to invest time to sort out lib's internals. Its all on you now. I step back. Good luck.

@popravich - I'm sorry to see you step back but I respect and appreciate your honesty.
@gnat - Thank you for the kind words of support.
I've taken a few days to respond because I wanted to step back and reflect on the long discussion we've had in this PR. I still do believe this is the correct path forward for now, and with the blessing of the community I will continue to push this PR forward. There is still a lot of work to be done on the documentation, which I'm hoping to have done in the coming weeks. At that point, I think we could target a v2.0.0a1 release with this port.
As @popravich has requested, once this PR is merged, I will also look at renaming the repository to aioredis-py to better reflect that this will be a running asyncio-based port of redis-py, rather than a custom implementation, as aioredis was.
At the end of the day, everyone here wants to see this community and library not only survive, but flourish. I look forward to continued collaboration as we continue our work.

Will the package be renamed as well? @seandstewart

No, I think we’d follow the redis-py convention (yet again). The repo is
aioredis-py and the package is aioredis.
On March 1, 2021, GitHub Notifications<EMAIL_ADDRESS>wrote:

Will the package be renamed as well? @seandstewart
https://github.com/seandstewart

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/aio-
libs/aioredis/pull/891#issuecomment-788153781>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AEVL37UGI2BYBPCFPYQISILTBPJOLANCNFSM4WSLEQIA>.

@seandstewart Any ETA on first release?

I'm hoping to finish up documentation this weekend, then perhaps get an alpha release out by end of next week!
Thanks everyone for your continued patience. I do believe this will enable a much faster iteration cycle moving forward, but it's a Big Change :tm: to get pushed through.

Gonna +1 @popravich here and say it seems like the better place to do this is aredis, which is already an asyncio port of redis-py.
To @Andrew-Chen-Wang's point, aredis is open source too, so if it's not exactly maintained then you can... help maintain it. But doesn't really make sense to me to have two open source asyncio redis libs that are both just redis-py ports. Lots of talk about how "this is the easier way", but seems like the easiest way would've been to just help maintain aredis. This on the other hand is duplication of effort already done in the aredis lib.
If there is more than one way to solve the problem, having a "sole" asyncio redis lib for python sounds like a bug, not a feature. Trying to morph one lib to look like another lib (for "maintainability") because the first one "has more stars" is silly. Maintain aredis and it will soon have more stars.
Also looking at the benchmarks from the aredis repo (which again, is based off redis-py), the performance doesn't seem much different between aioredis and aredis, with redis-py being faster than both.

@acnebs The problem is who has merging capabilities in these repositories? Only the owners. Why hasn't anyone else taken the torch? The best people can do is make forks and rename the package, but that rarely happens. Well I guess this PR is a special case then.

If there is more than one way to solve the problem, having a "sole" asyncio redis lib for python sounds like a bug

Diversity's great when there are multiple problems or one with multiple hidden layers software wise. There's really only one for port libraries with one layer of issues. Why do most organizations use psycopg2, redis-py, tensorflow's only Python binding lib, etc.? When they're widely used, they're trusted hence a GitHub star system. It's exactly why there's a market for tech stack websites. People like to use the best there is.
Regarding maintainability, we're all volunteers with school or work. So yes, maintainability is somewhat key. There are easy libraries to understand like Django, redis-py, and aredis where many contributors come to help out. Or there are harder ones like uWebsockets where no one understands it but the owner. And if the owner disappears? Well then the product is just decaying code.
That's just my opinion; I also agree I would like for us to keep the current aioredis code and improve upon it, but to what extent are we all capable of it based on our time and commitment?

Again, if someone (anyone) has the time to maintain a version of aioredis that is effectively just an asyncio port of redis-py, why not just... have a go with aredis? Have you tried asking for perms over there? If not, why not? Seems like that is a much better place to start than here. If the maintainer is unresponsive/AWOL, you can also just fork aredis. That still seems like a better path forward than this approach.
This is not "maintaining" aioredis, this is wholesale replacing it and just trading off the name because it's the most popular lib, as you pointed out yourself.

If not, why not?

No, because I'm running low on time since I'm an inefficient person, but for others looking: NoneGG's email is in his profile. I've relinquished my role of maintaining in a few repos already but hanging tight here if Sean wants some minor assistance; overlooking another repo brings more responsibilities than I personally think I can handle, and I can't handle it.

@acnebs -
Thanks for submitting your feedback to this PR. I understand your gut reaction to this change, but I also feel it lacks context.

it seems like the better place to do this is aredis, which is already an asyncio port of redis-py

You're correct in that aredis started as a direct port of redis-py, but it most definitely not true any longer. The implementation in aredis has diverged significantly since its creation in 2017 and maintenance has dropped off, leaving yet another async redis library without support.
I did not take over maintainership of aioredis with the goal of replacing the implementation. I took over maintainership because there hadn't been an active maintainer for over a year and I wanted to make sure this library and community didn't die out. I spent the end of last year and into the start of this one digging into the code and triaging tickets. During that time I came to the conclusion that it just wasn't possible for the community to realistically support the current implementation of aioredis. If I want to achieve my goal of ensuring this library can be community-supported with minimal barrier to entry, then this is the correct path forward.
You're right, I'm completely replacing the original implementation of aioredis with this change. But software is not sacred. Software is temporary, software is always evolving. We should accept that something like this could occur. A library like aioredis exists for the express purpose of supplying developers with a compliant client for working with Redis in an asyncio context. It does not exist for the maintainer or for the sanctity of its implementation. If we wish to maintain an archive of v1, then we can easily create an archival branch with that implementation, that's what version control is for. There was a period during the course of this PR w the original maintainer looked willing to return and work with us to fix the connection and pipeline implementations, but that period has passed and they have officially stepped back, citing a lack of time to  devote to such work. I understand that decision and support it. This change is an acknowledgement of such limitations.
Of course any of us could fork the library and maintain our own port or set of code. That's not the goal. The goal is to revive this library and ensure the community which already exists continues having access to a high-quality, asyncio-native library for working with Redis.
I hope you understand this decision and can respect the intent, which is to help the community. At the end of the day, the decision is made and I will be moving forward with this change once I feel the documentation is ready to support it.

I'd also like to add that this isn't the end, this is another beginning. If the community of contributors grows (which is my hope) then perhaps we change course at that point and bring back some of the patterns from v1 that are desirable. The software will change and evolve with the group that chooses to maintain it, but we need that group to exist first.

Just, please, don't publish this aioredis-py as aioredis package.  This is essentially a new project, with different API, it should have a different package name.

Hey @gjcarneiro -
I understand how you feel. To say this is a large change is an understatement.
I would like to stress, however, that the client-facing API is largely the same.
Any differences in the signatures of commands are changes that were either needed to add support for changes in Redis or the result of having a very unique implementation of the command.
Changes to the connection management to align with the redis-py implementation should not dramatically alter how the client is used or initiated either, as asynchronous contexts are still supported, as will as checking out single connections.
Top-level transactions have not changed, and in fact should have much better performance.
I don’t initially see the need to publish a new package given the fact that the major version will be bumped, indicating the fact that the API has changed. I also want to allow time before an official release, I won’t rush out a major change like this. There will be pre-releases, testing, and outreach to downstream dependencies.
Does this help assuage your concerns?

It doesn't have the MPSC module (aioredis.pubsub.Receiver), which I use in a lot of places.  client.setex() used to accept a float as well as int.  Just two examples of API changes off the top of my head.  I'm sure there are plenty more.
I don't have time or motivation to port old code to a new API.  You're just going to force me to pin aioredis<2 requirement I guess.  Even that is problematic, I have to remember all the modules where I use aioredis, to add this pin.  Others will get more "surprised".
OTOH, kudos for giving it type annotations.  I wanted type hints for a long time in aioredis. :+1:
It's a cool project, but I wish it was a separate project.

It doesn't have the MPSC module (aioredis.pubsub.Receiver), which I use in a lot of places.

I can see now how removing those abstractions could be a pretty large blocker for some. Could you create an issue describing how you use the Channel/Reciever abstraction? I can look at adding it back in, perhaps as a contrib or ext module to denote that it is an extension over the default implementation.

client.setex() used to accept a float as well as int.

Regarding setex, accepting float for that value is actually disingenuous, as the Redis command expects an integer value in seconds: https://redis.io/commands/setex. If you need millisecond precision, psetex should be used, also with a whole  integer value: https://redis.io/commands/psetex. The original implementation hid this detail, but that is an implicit action which could lead to surprising behavior.

@seandstewart Do you mind triggering the ReadTheDocs for the alpha release? I'm not sure if publishing the alpha release to PyPi will force everyone to update (e.g. on PyJWT, they published alpha and beta releases in the same format as you did, but dependabot and pip didn't ask users to update) ref: #919

Yeah, I don't appear to have administrative access to ReadTheDocs and LGTM. I need administrator access to trigger builds and adjust configurations on those services. We just haven't needn't that access till now which is why it went overlooked. @asvetlov should be able to grant access. Additionally, as he's the owner of the project, he can work with @abrookins to get him set up with the correct access. Let's track all this in #822

@seandstewart, @Andrew-Chen-Wang, huge thank you for your efforts! I know I'm a bit late to answer Sean's requests for community verdict, but I have to say that I use aioredis heavily in a mission-critical production project (because it was an asyncio port with the most stars as said above and at the time also seemed relatively maintained) and your way of resurrecting it has my full support.
I'll feel much more confident about addressing breaking changes with a switch to the maintained port of redis-py than I would about relying on a stale codebase with known bugs and performance issues. As previous commenters, I'm grateful to @popravich and other maintainers of the original codebase for the working version which we currently use. But I was seriously considering moving away from redis to a different message broker/in-memory cache product just because a major part of our code is asyncio-based and with growing user base and system load we would not be able to keep ignoring issues like performance, pipeline transactions and cluster support. I also saw issues with reconnection logic which I didn't get around to understanding better and reporting.
A note on Windows support: redis 5 and later can't run on Windows, but we still need to use the client lib on Windows as this is where do most coding and debugging.

What happened to the CHANGES/ additions?