keep-alive component in nested route result in child route mounted twice

Version
3.0.3
Reproduction link
https://codesandbox.io/s/nifty-roentgen-67uyr
without vue router
Steps to reproduce
There is 5 files in the project. These files are App.vue, UserCenter/Index.vue, UserCenter/Push.vue, List/Index.vue, List/Detail.vue. Two Index.vue files are the child routes of App.vue, and I wrote keep-alive in App.vue. Push.vue and Detail.vue are child routes of two Index.vue, and I wrote keep-alive in two Index.vue to cache them.Here is the step to reproduce:

First, open the sandbox link and open console, you will find the console print 'app loading';
Second, click 'push page' link, console print 'user center loading... ' and 'push loading... ';
Third, click 'detail page' link, console print 'list loading...' and 'detail loading...' twice;
Forth, navigate back to previous push page, console print 'push loading' again.

What is expected?
In step 3, I just expect it print once; In step4, it's not supposed to print again;
What is actually happening?
In these circumstance, I found the child route mount twice;And about step 4 in my project, I found the cache did function, but it did mount again, which was confusing.

@LiHDong moved to vue-router repo for the moment
The problem comes from the nested router-view inside UserCenter: because it's kept alive, it reacts to route changes and tries to render with the new nested view. I will see if there is a way to prevent this.

The problem is the same as https://github.com/vuejs/vue/issues/8819 which I don't know if it's expected or not. @yyx990803 is it normal for an inactive kept-alive component to keep rendering while inactive?
In the context of vue-router I tried internally avoiding rendering the router-view when the component is inactive, but it's too late, it still gets to mount the children once, resulting in mounting two Detail pages. So I tried not changing the route for nested router views but it turns out the onDeactivated hook triggers after computed based on the current route location, not allowing me to pass the old version of a route
// getting the global route or a route injected by a parent router-view
const injectedRoute = inject(routerViewLocationKey, inject( routeLocationKey));
        onDeactivated(() => {
            console.log('deactivated', depth)
        })
        const myRoute = computed(() => {
            console.log('computing myRoute')
            return (props.route || unref(injectedRoute))
        })
// providing the route to nested router-view
        provide(routerViewLocationKey, myRoute)

This prints computing myRoute and then deactivated. If it was the other way around, I could have cached the previous value of myRoute.

@posva Is there a solution to this problem?

Also ran into the mounted issue in nested routes when using keep-alive, which causes repeated calls to the database :(
Didn't find a solution :(
<EMAIL_ADDRESS><EMAIL_ADDRESS>

Also ran into the mounted issue in nested routes when using keep-alive, which causes repeated calls to the database :(
Didn't find a solution :(
<EMAIL_ADDRESS><EMAIL_ADDRESS>

@posva @yyx990803 Is there any progress on this, please. Has affected the normal progress of the project

@posva @yyx990803 Is there any progress on this, please. Has affected the normal progress of the project

Also ran into the mounted issue in nested routes when using keep-alive, which causes repeated calls to the database :(
Didn't find a solution :(
<EMAIL_ADDRESS><EMAIL_ADDRESS>
Me too, I think this is a serious problem,

Also ran into the mounted issue in nested routes when using keep-alive, which causes repeated calls to the database :(
Didn't find a solution :(
<EMAIL_ADDRESS><EMAIL_ADDRESS>
Me too, I think this is a serious problem,

@danitatt Did you solve this problem？

Same problem here since from the beta version and to the v4.0.5

my component named SubModuleA.vue, its activated deactivated twice
https://codesandbox.io/s/cool-galois-f055n

I also have a similar problem. Is there any solution.

Hello, Happy new year everyone !
This issue affects performance and kind of defeats the purpose of kept-alive router-views on vue 3.
For example (excessive demo based on a real life observation):
Using keep alive: we see the double mount.
Total time : 2.08s

Not using keep alive: single mount.
Total time : 1.11s

We can see here that changing page is twice slower if router-view is wrapped in keep-alive tag.
Worth noting that using keep-alive in vue 2 in the exact same scenario we get a total time of around 0.7s, 3x faster :(
(I can create a reproduction if needed)

It also seems that the activated event is triggered on the component that gets deactivated.
Reproduction here : https://github.com/nicolas-t/vue-3-keep-alive-lifecycle
Demo here : https://vue-3-keep-alive-lifecycle.netlify.app/home/nested
Related topic : https://forum.vuejs.org/t/vue-3-keep-alive-lifecycle-issue/125549

I know it's been more than a year since this issue has been opened, but is there anything we can do to help ?
It's blocking me and maybe others to migrate from vue 2 to vue 3 at the moment.
Thanks :)

This is also true when using nested <Suspense> rather than <KeepAlive>: https://codesandbox.io/s/lively-mountain-o395nx. It feels like the cause is likely similar, but I'm happy to open a new issue if you think not.

Hi,
I have a similar issue with two nested QRouteTab component (from Quasar).
Reproduction link: https://codesandbox.io/s/without-qtabpanel-m43nec
If you click ont "test B" tab, the setup of test j is executed twice.
Console output of navigation between tabs: Test A (test i) -> test ii -> Test B (test j)
[Quasar] Running SPA.
##### setup -> index
##### setup -> layout test A
##### setup -> test i
##### setup -> layout test B
##### setup -> test j
##### setup -> test j

Also it seems that child component need to be mounted twice before to "keep-alive correctly".
Example: if you comeback on test A the setup of "test i" is rerun. Then, you can navigate between both tabs without additional mount:
Console output of navigation between tabs: Test A (test i) -> test ii -> Test B (test j) -> Test A (test i) -> test ii -> test iii
[Quasar] Running SPA.
##### setup -> index
##### setup -> layout test A
##### setup -> test I                          # first time
##### setup -> test ii                         # first time
##### setup -> layout test B
##### setup -> test j
##### setup -> test j
##### setup -> test i                           # second time
##### setup -> test ii                          # second time
##### setup -> test iii
##### setup -> test iii

If you think this issue can be fixe with a cleaner code (good practice), I will thank you in advance for your help.

I made a minimal reproducible example using<EMAIL_ADDRESS>here: https://codesandbox.io/s/gifted-gagarin-g3ugux?file=/src/main.js
It contains two child router-view, one uses keep-alive and the other one does not, and when navigating from /a/a to /b/a, the setup function in BA.vue logged twice.

In 2022, it seems the bug still exists. If keep-alive nested routes are used, the render is repeated

记录
vue-router 4.0.15
子路由组件被两次初始化

第二次时，调用 inject 会报：[Vue warn]: injection "xxx" not found.

onActivated 和 onDeactivated 子页面进来和退出都会被调用

进来页面先调用 onDeactivated ，再调用 onActivated
退出页面先调用 onDeactivated ，再调用 onActivated，后再调用 onDeactivated

Deadalusmask's repro code shows one RouterView with a KeepAlive and one without.  It seems to me that even if there are no KeepAlives in the nested RouterViews, the mounted and created hooks still fire twice in the child components: https://stackblitz.com/edit/vue-wvgvfa?file=src%2FApp.vue  Navigate back and forth between Child1 and Child2 using the links and notice that created, mounted, and unmounted fire multiple times.  For example, here's the result of navigating from Child1 to Child2.
Child2 created
Child2 created
Child1 unmounted
Child2 mounted
Child1 unmounted
Child2 mounted

I might take a stab at fixing this issue.  I'm not familiar with the Vue Router code, so any hints on where to start would be helpful.  Also, the documentation is (IMO) not clear in regard to using KeepAlive in RouterView's slot.  Specifically, it's not clear to me if child components should be persisted in cache when the top-most RouterView uses KeepAlive, or if nested RouterViews should be required to use KeepAlive.  My assumption is that the latter case is correct, but this part of the documentation seems contradictory:

When a component instance is removed from the DOM but is part of a component tree cached by , it goes into a deactivated state instead of being unmounted. When a component instance is inserted into the DOM as part of a cached tree, it is activated.

记录
vue-router 4.0.15
子路由组件被两次初始化

第二次时，调用 inject 会报：[Vue warn]: injection "xxx" not found.

onActivated 和 onDeactivated 子页面进来和退出都会被调用

进来页面先调用 onDeactivated ，再调用 onActivated
退出页面先调用 onDeactivated ，再调用 onActivated，后再调用 onDeactivated

记录
vue-router 4.0.15
子路由组件被两次初始化

第二次时，调用 inject 会报：[Vue warn]: injection "xxx" not found.

onActivated 和 onDeactivated 子页面进来和退出都会被调用

进来页面先调用 onDeactivated ，再调用 onActivated
退出页面先调用 onDeactivated ，再调用 onActivated，后再调用 onDeactivated

我也因为 inject 的问题找到这儿，发现被 keep-alive 保活后，子组件 setup 中会执行两次

测试使用 vue-router 版本：4.0.12
@lin09 我也因为 inject 的问题找到这儿，发现多层 router-view 的情况下，如果有 keep-alive 保活，那么子组件 setup 中会执行多次，执行的次数取决于同级的 keep-alive 的数量
测试时在 vue-devtools 中可以看到预料之外的层级关系，组件出现在不该出现的位置，导致存在三份组件，所以 setup 中的代码执行了三次
这是我的路由表，其中 app.vue、index.vue、letter.vue、number.vue、car.vue 中的 router-view 都使用了 keep-alive
<router-view v-slot="{Component}">
    <keep-alive>
        <component :is="Component"/>
    </keep-alive>
</router-view>

const routes = [
  {
    path: "/",
    redirect: {
      name: "index"
    }
  },
  {
    path: "/index",
    name: "index",
    component: () => import("/src/views/index.vue"),
    redirect: {
      name: "letter"
    },
    children: [
      {
        path: "letter",
        name: "letter",
        component: () => import("/src/views/letter/letter.vue"),
        redirect: {
          name: "letterA"
        },
        children: [
          {
            path: "letterA",
            name: "letterA",
            component: () => import("/src/views/letter/a.vue")
          }
        ]
      },
      {
        path: "number",
        name: "number",
        component: () => import("/src/views/number/number.vue"),
        redirect: {
          name: "numberOne"
        },
        children: [
          {
            path: "numberOne",
            name: "numberOne",
            component: () => import("/src/views/number/one.vue")
          }
        ]
      },
      {
        path: "car",
        name: "car",
        component: () => import("/src/views/car/car.vue"),
        redirect: {
          name: "carBmw"
        },
        children: [
          {
            path: "carBmw",
            name: "carBmw",
            component: () => import("/src/views/car/bmw.vue")
          }
        ]
      }
    ]
  }
];

I use onActivated and onDeactivated to solve issue. Set a parameter isActiveusing these hooks
<router-view v-if="isActive" />

I use onActivated and onDeactivated to solve issue. Set a parameter isActiveusing these hooks
<router-view v-if="isActive" />
Yes it is ugly and adds unnecessary complexity to the code.

Could you paste your project， thanks！

is it possible to have this issue pinned?

Continue to nested Keepalive in Keepalive  can fix this bug https://codesandbox.io/s/modest-thompson-klqcel

But it throws an error in the console，

By viewing the keepalive source code, I found that the parentComponent.ctx should be of type KeepAliveContext,The console error is because the parentComponent at this time is not keepalive

So I tried to modify the source code to circumvent this problem, and the activate hook handles the same

I don't think this is a good way to modify it, but it doesn't require modifying the routing hierarchy

I had the same problem 🥲🥲🥲
https://github.com/vuejs/core/issues/7057

Hello, Happy new year everyone !
This issue affects performance and kind of defeats the purpose of kept-alive router-views on vue 3. For example (extreme demo based on a real life observation):
Using keep alive: we see the double mount. Total time : 2.08s
Not using keep alive: single mount. Total time : 1.11s
We can see here that changing page is twice slower if router-view is wrapped in keep-alive tag. Worth noting that using keep-alive in vue 2 in the exact same scenario we get a total time of around 0.7s, 3x faster :( (I can share a reproduction if needed)
It also seems that the activated event is triggered on the component that gets deactivated. Reproduction here : https://github.com/nicolas-t/vue-3-keep-alive-lifecycle Demo here : https://vue-3-keep-alive-lifecycle.netlify.app/home/nested
Related topic : https://forum.vuejs.org/t/vue-3-keep-alive-lifecycle-issue/125549
I know it's been more than a year since this issue has been opened, but is there anything we can do to help ? It's blocking me and maybe others to migrate from vue 2 to vue 3 at the moment.
Thanks :)

It's been another year

有好的临时解决方案吗？

有好的临时解决方案吗？

尝试将多级嵌套路由打成平级

有好的临时解决方案吗？

尝试将多级嵌套路由打成平级
vbenjs/vue-vben-admin#215 (comment)

事实上我所需的功能就是需要多级路由，平铺的结构会带来很多其他问题，这还真是个远古bug

有好的临时解决方案吗？

可以试下命名视图

有好的临时解决方案吗？

可以试下命名视图

这个命名视图是指什么

有好的临时解决方案吗？

尝试将多级嵌套路由打成平级
vbenjs/vue-vben-admin#215 (comment)

事实上我所需的功能就是需要多级路由，平铺的结构会带来很多其他问题，这还真是个远古bug

你可以在注册路由的时候打平结构就好了，其他地方还是保留原有的层级

有好的临时解决方案吗？

尝试将多级嵌套路由打成平级
vbenjs/vue-vben-admin#215 (comment)

事实上我所需的功能就是需要多级路由，平铺的结构会带来很多其他问题，这还真是个远古bug

你可以在注册路由的时候打平结构就好了，其他地方还是保留原有的层级

可能你没有理解我的意思，就是我的需求就是有三级路由，比如主 layout 下面有个页面有自己的 layout,这个layout 下有三级路由，而且也是通过 router-view 去渲染的。这个三级路由的 bug 是 setup 中的内容不会在重复进入时重复执行

或许x-255提供的方式可能会适合你

Continue to nested Keepalive in Keepalive can fix this bug app is the first level ,amd、cmd is the second,Their routing methods are as follows https://codesandbox.io/s/modest-thompson-klqcel  However, this will cause setup to execute multiple times

Can the setup be performed only once?

测试使用 vue-router 版本：4.0.12
@lin09 我也因为 inject 的问题找到这儿，发现多层 router-view 的情况下，如果有 keep-alive 保活，那么子组件 setup 中会执行多次，执行的次数取决于同级的 keep-alive 的数量
测试时在 vue-devtools 中可以看到预料之外的层级关系，组件出现在不该出现的位置，导致存在三份组件，所以 setup 中的代码执行了三次
这是我的路由表，其中 app.vue、index.vue、letter.vue、number.vue、car.vue 中的 router-view 都使用了 keep-alive
<router-view v-slot="{Component}">
    <keep-alive>
        <component :is="Component"/>
    </keep-alive>
</router-view>

const routes = [
  {
    path: "/",
    redirect: {
      name: "index"
    }
  },
  {
    path: "/index",
    name: "index",
    component: () => import("/src/views/index.vue"),
    redirect: {
      name: "letter"
    },
    children: [
      {
        path: "letter",
        name: "letter",
        component: () => import("/src/views/letter/letter.vue"),
        redirect: {
          name: "letterA"
        },
        children: [
          {
            path: "letterA",
            name: "letterA",
            component: () => import("/src/views/letter/a.vue")
          }
        ]
      },
      {
        path: "number",
        name: "number",
        component: () => import("/src/views/number/number.vue"),
        redirect: {
          name: "numberOne"
        },
        children: [
          {
            path: "numberOne",
            name: "numberOne",
            component: () => import("/src/views/number/one.vue")
          }
        ]
      },
      {
        path: "car",
        name: "car",
        component: () => import("/src/views/car/car.vue"),
        redirect: {
          name: "carBmw"
        },
        children: [
          {
            path: "carBmw",
            name: "carBmw",
            component: () => import("/src/views/car/bmw.vue")
          }
        ]
      }
    ]
  }
];

有好的解决方法吗？

有好的临时解决方案吗？

有的

有好的临时解决方案吗？

有的

这是一个最小的复现demo:https://github.com/Miofly/vue-keep-alive-issue
应该如何去解决呢

Here is my issue and my solution
I have a root tabs route and a secondary route (tab1, tab2)
tabs meta:{keepAlive: true}
tab1 meta:{keepAlive: true}
tab2 meta:{keepAlive: false}
when I from tab1 navigate to tab2, the tab1 created will be trigger first and then tab2 created will be trigger
app.vue
<keep-alive>
  <router-view v-if="$route.meta.keepAlive"></router-view>
</keep-alive>
<router-view v-if="!$route.meta.keepAlive"></router-view>

tabs.vue
<tabs>
  <tab1 />
  <tab2 />
</tabs>

<keep-alive>
  <router-view v-if="$route.meta.keepAlive"></router-view>
</keep-alive>
<router-view v-if="!$route.meta.keepAlive"></router-view>

my situation solution
I change the root view to this
app.vue
<keep-alive>
  <router-view v-if="$route.matched[0].meta.keepAlive"></router-view>
</keep-alive>
<router-view v-if="!$route.matched[0].meta.keepAlive"></router-view>

guess the reason
$route represents the current route, which means that if you enter the secondary route, the view in the top route will also change accordingly
$route.matched[0] represents the top route of current route
I do not know if this is right thinking, but at least, it solved my problems

Hello any update?

有好的临时解决方案吗？

有的

There is a temporary solution, I can come up with a plug-in later, but it should be noted that the life cycle of the cache will still be called twice in essence, but the life cycle of multiple calls is blocked through the plug-in.

有好的临时解决方案吗？

有的

There is a temporary solution, I can come up with a plug-in later, but it should be noted that the life cycle of the cache will still be called twice in essence, but the life cycle of multiple calls is blocked through the plug-in.

thanks, wait plugin

Here's a hack I'm using to prevent the wrong child routes from mounting:
Setup some computed properties to get the child routes for the parent component
    computed: {
        routeNames() {
            const parent = this.$router.options.routes.find(route => route.name === YOUR_PARENT_ROUTE);
            const routes = parent && parent.children || [];
            return this.routes.map(route => route.name);
        }
    }

Add a v-if to the Component
<RouterView v-slot="{ Component }">
    <KeepAlive>
        <Component
            :is="Component"
            v-if="routeNames.includes($route.name)"
        />
    </KeepAlive>
</RouterView>

It's kinda nasty and fetching the $router options is not super recommended but it works 🤷

大家好，新年快乐！
这个问题会影响性能，并且会破坏 vue 3 上 keep-alive router-views 的目的。例如（基于现实生活观察的极端演示）：
使用 keep alive：我们看到双重安装。总时间：2.08s
不使用 keep alive：单挂载。总时间：1.11s
router-view我们可以在这里看到，如果包装在标签中，则更改页面会慢两倍keep-alive。值得注意的是，keep-alive在完全相同的场景中使用 vue 2，我们得到的总时间约为 0.7 秒，快了 3 倍 :(（如果需要，我可以分享复制品）
似乎activated事件是在获取的组件上触发的deactivated。复制在这里： https: //github.com/nicolas-t/vue-3-keep-alive-lifecycle演示在这里：https://vue-3-keep-alive-lifecycle.netlify.app/home/nested
相关主题：https ://forum.vuejs.org/t/vue-3-keep-alive-lifecycle-issue/125549
我知道这个问题已经打开一年多了，但是有什么我们可以帮忙的吗？目前，它阻止了我和其他人从 vue 2 迁移到 vue 3。
谢谢 ：）

又过了一年😭

欸 这个问题可能不会解决了

@posva @yyx990803 This issue has been around for two years now. I don't think this issue has such a low processing priority because essentially it's not a performance optimization, it's a logic error. ☹

This hasn't advanced yet as noted in https://github.com/vuejs/router/issues/626#issuecomment-736355520.

It is so disappointing.This is really a logic issue and be opened for such a long time.

I have been working for 3 days for this issue. But I can not handle it. Anybody did it?

Why is this issue so low priority, many things are now forced to use only secondary routing

any news on this issue?

I created a custom  component as workaround fix to this bug:  vue3-keep-alive-component (https://github.com/emiyalee1005/vue3-keep-alive-component).
For anyone who encounter the issue can have a try to this

The Problem
After some investigation, it seems this bug is down to a fairly complex interaction between KeepAlive and RouterView when using nested routes.
Also, the bug results in the child route component being mounted for EVERY RouterView instance in pages at that same depth.
Example
So, for example, if we have the following structure....
Page A
-- Page A-A
Page B
-- Page B-A
Page C
--Page C-A
Performing the following steps in-order will produce these results:

Navigate to Page A-A:
Mounts "Page A-A" component within "Page A" (as expected)
Navigate to Page B-A:
Mounts "Page B-A" component within "Page B" (as expected)
Mounts "Page B-A" component within "Page A" (NOT as expected)
Navigate to Page C-A:
Mounts "Page C-A" component within "Page C" (as expected)
Mounts "Page C-A" component within "Page A" (NOT as expected)
Mounts "Page C-A" component within "Page B" (NOT as expected)

Explanation
This seems to be because each nested RouterView component is kept alive. This results in all nested RouterView components continuing to update even when they are deactivated. In and of itself this wouldn't be too bad, but unfortunately the RouterView component doesn't distinguish between which parent RouterView instantiated it, therefore in the above scenario, the RouterView components in "Page A", "Page B" and "Page C" all attempt to render all pages at their depth, e.g. "Page A-A", "Page B-A" and "Page C-A".
Workaround Fix Component (FixedRouterView.vue)
I have come up with a fairly solid hack which works around the above mentioned issue which I have include in the codesandbox as "FixedRouterView.vue"
https://codesandbox.io/s/brave-river-yq7r6v?file=/src/components/FixedRouterView.vue
To use the codesandbox demo:
Reproduce Issue
Open the console
Click through the pages at the top and see the duplicate console.log messages
With Fix Applied
Reload the page
Toggle the "Apply Fix" checkbox (which enables the FixedRouterView logic)
Now again click through the pages at the top and you will not see any duplicate console.log messages

We have to do something very similar in Nuxt.

@peteclark82's component is a very useful workaround. If anyone is looking for a TypeScript variant, it's below.

See code
<template>
  <RouterView v-slot="{ Component, route }">
    <slot
      v-bind="{
        Component: getComponent(Component, route),
        route,
      }"
    />
  </RouterView>
</template>

<script setup lang="ts">
import {
  type RouteLocationNormalizedLoaded,
  type RouteRecordName,
  type RouteRecordRaw,
  RouterView,
  useRoute,
} from 'vue-router';
import { type VNode, inject, onBeforeMount, provide, ref } from 'vue';

type Component = VNode;

type RouterViewEntry = {
  children: RouteRecordRaw[] | undefined;
  depth: number;
  name: RouteRecordName | undefined;
};

const currentRoute = useRoute();

const childRoutesDict: Record<string, RouteRecordName> = {};

const storedComponent = ref<Component | null>(null);
const currentRouterView = ref<RouterViewEntry | null>(null);

const parentRouterView = inject<RouterViewEntry | null>(
  'parentRouterView',
  null
);

provide('parentRouterView', currentRouterView);

function setRouterView() {
  const depth = getRouterViewDepth();
  const matchedRoute = currentRoute.matched[depth];

  currentRouterView.value = {
    children: matchedRoute?.children,
    depth,
    name: matchedRoute?.name,
  };
}

function getRouterViewDepth() {
  if (typeof parentRouterView?.depth === 'undefined') {
    return 0;
  }

  return parentRouterView.depth + 1;
}

function getComponent(
  component: Component | undefined,
  route: RouteLocationNormalizedLoaded
) {
  if (component) {
    storeChildComponent(component, route);
    tryToOverrideStoredComponent(component);
  }

  return component;
}

function storeChildComponent(
  component: Component,
  route: RouteLocationNormalizedLoaded
) {
  const key = getComponentKey(component);

  if (!key) {
    console.warn('Invalid key. Buggy behavior is happening.');
    return;
  }

  if (!childRoutesDict[key]) {
    const currentRouterViewDepth = currentRouterView.value?.depth ?? 0 + 1;
    const childComponentRouteMatch = route.matched[currentRouterViewDepth];
    const routeName = childComponentRouteMatch?.name;

    if (routeName) {
      childRoutesDict[key] = routeName;
    }
  }
}

function tryToOverrideStoredComponent(component: Component) {
  if (isComponentOfCurrentRouterView(component)) {
    storedComponent.value = component;
  }
}

function isComponentOfCurrentRouterView(component: Component) {
  const key = getComponentKey(component);

  if (!key || !currentRouterView.value?.children) {
    return false;
  }

  const isMatch = currentRouterView.value.children.some(({ name }) => {
    return name === childRoutesDict[key];
  });

  return isMatch;
}

function getComponentKey(component: Component) {
  if (typeof component.type === 'object') {
    if ('__name' in component.type) {
      return component.type.__name;
    } else if ('name' in component.type) {
      return component.type.name;
    }
  }
}

onBeforeMount(() => {
  setRouterView();
});
</script>

The Problem
After some investigation, it seems this bug is down to a fairly complex interaction between KeepAlive and RouterView when using nested routes.
Also, the bug results in the child route component being mounted for EVERY RouterView instance in pages at that same depth, not necessarily just TWICE.
Example
So, for example, if we have the following structure....
Page A -- Page A-A Page B -- Page B-A Page C --Page C-A
Performing the following steps in-order will produce these results:

Navigate to Page A-A:
Mounts "Page A-A" component within "Page A" (as expected)
Navigate to Page B-A:
Mounts "Page B-A" component within "Page B" (as expected)
Mounts "Page B-A" component within "Page A" (NOT as expected)
Navigate to Page C-A:
Mounts "Page C-A" component within "Page C" (as expected)
Mounts "Page C-A" component within "Page A" (NOT as expected)
Mounts "Page C-A" component within "Page B" (NOT as expected)

Explanation
This seems to be because each nested RouterView component is kept alive. This results in all nested RouterView components continuing to update even when they are deactivated. In and of itself this wouldn't be too bad, but unfortunately the RouterView component doesn't distinguish between which parent RouterView instantiated it, therefore in the above scenario, the RouterView components in "Page A", "Page B" and "Page C" all attempt to render all pages at their depth, e.g. "Page A-A", "Page B-A" and "Page C-A".
Workaround Fix Component (FixedRouterView.vue)
I have come up with a fairly solid hack which works around the above mentioned issue which I have include in the codesandbox as "FixedRouterView.vue".
The fix allows each nested RouterView to determine which section of the router config it is responsible for and ensures that it only renders page components from within that section.
https://codesandbox.io/s/brave-river-yq7r6v?file=/src/components/FixedRouterView.vue
To use the codesandbox demo:
Reproduce Issue Open the console Click through the pages at the top and see the duplicate console.log messages
With Fix Applied Reload the page Toggle the "Apply Fix" checkbox (which enables the FixedRouterView logic) Now again click through the pages at the top and you will not see any duplicate console.log messages

You're really amazing. Why don't you modify his source code? It's not very convenient to write and use like this。I have become a first level router view. There should be no problem loading multi-level child routing

@posva Considering the comment from @peteclark82, do you still believe this is due to https://github.com/vuejs/vue/issues/8819?

@posva @yyx990803 This issue has been existing for three and a half years without any progress. It significantly affects multi-layout routing switching in mobile web applications and should not have been ignored for so long.

My issue mainly lies in the multiple triggers of onMounted.
I’m sharing a rough approach here as a reference for discussion.
from: https://github.com/duanluan/wuyou-boot-ui/commit/37d2dd185d64f66b3718b8dd2bb7a574556eabd7
src/util/debounceLifecycle.ts:
import {onMounted} from 'vue'
import * as CryptoJS from 'crypto-js';

const debounceMap: Map<string, number> = new Map();

const debounceExecution = (callback, delay = 300) => {
  const key = CryptoJS.SHA256(callback.toString()).toString()

  if (debounceMap.has(key)) {
    clearTimeout(debounceMap.get(key))
    debounceMap.delete(key)
  }
  const timeout = setTimeout(() => {
    debounceMap.delete(key)
    callback()
  }, delay)
  debounceMap.set(key, timeout)
}

const onDebounceMounted = (callback, delay = 300) => {
  onMounted(() => {
    debounceExecution(callback, delay)
  })
}

export {onDebounceMounted}

src/view/sys/RolesView.vue
<script setup lang="ts">
import {onDebounceMounted} from<EMAIL_ADDRESS>
onDebounceMounted(async () => {
  search()
})
<script>


Colors chosen in the konsole profile do not match the names in terminal configuration.

Red is not really red, green is not green etc. Maybe we should reorder the colors in Konsole (which are unfortunately only called Color1 to Color8) to more closely match the names they have in the terminal.

I just rechecked and I think one cannot get any closer than it is now without changing the colors.


TomographyModel expparams_dtype broken in Python 2

The Python 3 port at one point required unicode_literals to be turned on for tomography/models.py, landing us right in the fallout from numpy/numpy#2407. As a result, TomographyModel.expparams_dtype is not understood by np.empty, np.array and friends:
TypeError                                 Traceback (most recent call last)
<ipython-input-82-aeaa035a166b> in <module>()
      1 updater = qi.SMCUpdater(model, 20000, prior)
----> 2 expparams = np.empty((1,), dtype=model.expparams_dtype)

TypeError: data type not understood

Until we can fix this, a work around is to manually creating expparam arrays with field names specified as str.

If you can write me a test for thiz that passes in py3 but fails in py2
I'll get on it :D
On May 20, 2016 8:11 AM, "Chris Granade"<EMAIL_ADDRESS>wrote:

The Python 3 port at one point required unicode_literals to be turned on
for tomography/models.py, landing us right in the fallout from
numpy/numpy#2407 https://github.com/numpy/numpy/issues/2407. As a
result, TomographyModel.expparams_dtype is not understood by np.empty,
np.array and friends:
TypeError                                 Traceback (most recent call last)
 in ()
1 updater = qi.SMCUpdater(model, 20000, prior)
----> 2 expparams = np.empty((1,), dtype=model.expparams_dtype)
TypeError: data type not understood
Until we can fix this, a work around is to manually creating expparam
arrays with field names specified as str.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/QInfer/python-qinfer/issues/59

Forgot to come back to this one, but a @csferrie found a simple test case today:
>>> import numpy as np
>>> import qinfer as qi
>>> basis = qi.tomography.pauli_basis(1)
>>> model = qi.tomography.TomographyModel(basis)
>>> expparams = np.empty((1,), dtype=model.expparams_dtype)
Traceback (most recent call last):
  File "<ipython-input-6-f2da9de3c693>", line 1, in <module>
    expparams = np.empty((1,), dtype=model.expparams_dtype)
TypeError: data type not understood

Turns out this is a really easy bug to fix. We just need to surround field names w/ str in files that have unicode_literals turned on. Since str returns a non-Unicode string on Python 2 and a Unicode string on Python 3, this has the effect of being fully compatible with NumPy's bizarre convention for field names on the respective versions.

Hmm. I see how this fixes it, but you'll have to be careful about importing the new str implementation into these files then. If you go from builtins import str, bytes to get the new functionality into Py2.7, then this will break again.

Agreed, it is a pain thanks to how futures defines newstr. Maybe it would
make sense to add a function field(name, dtype, shape) that calls
builtins.str instead of builtins.str or futures.str on its first
argument?
On Thu, Jun 9, 2016, 23:22 Steven Casagrande<EMAIL_ADDRESS>wrote:

Hmm. I see how this fixes it, but you'll have to be careful about
importing the new str implementation into these files then. If you go from
builtins import str, bytes to get the new functionality into Py2.7, then
this will break again.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QInfer/python-qinfer/issues/59#issuecomment-224892594,
or mute the thread
https://github.com/notifications/unsubscribe/AAB7HEysl69Ui-eFqq7Ot7BuNSb67uq_ks5qKBOogaJpZM4IjJHz
.

What is the actual requirement of these numpy functions? Can both Py2 and Py3 work with byte strings, or must it be byte for Py2 and unicode for Py3?
If both versions will accept byte strings, I'd do an from builtins import str, bytes and then make sure things are converted to bytes. But for some reason I feel that's not the case :(

In the NumPy issue thread, someone suggested that, but it turns out that NumPy basically has the worst behavior in this case, and demands bytes on Py2 and stron Py3. It's... kind of bizarre.

What is this, I don't even...
The only other solution is (ugh) checking what the primary python version is at run time, and doing a
from builtin import str, bytes
if sys.version_info[0] >=3:
    str(thing)
else:
    bytes(thing)

Otherwise, carry on then...


issues with sdk after download

downloaded the sdk for a react app ... and i get these errors ... is there any solution ?
ERROR in ./src/index.tsx 8:0-30
Module not found: Error: Can't resolve './styles/globals.css' in '/Users/theanti/Downloads/front/src'
ERROR in ./node_modules/cipher-base/index.js 2:16-43
Module not found: Error: Can't resolve 'stream' in '/Users/theanti/Downloads/front/node_modules/cipher-base'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "stream": require.resolve("stream-browserify") }'
- install 'stream-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "stream": false }
ERROR in ./node_modules/ethereumjs-util/dist.browser/account.js 34:31-48
Module not found: Error: Can't resolve 'assert' in '/Users/theanti/Downloads/front/node_modules/ethereumjs-util/dist.browser'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "assert": require.resolve("assert/") }'
- install 'assert'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "assert": false }
ERROR in ./node_modules/ethereumjs-util/dist.browser/address.js 12:31-48
Module not found: Error: Can't resolve 'assert' in '/Users/theanti/Downloads/front/node_modules/ethereumjs-util/dist.browser'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "assert": require.resolve("assert/") }'
- install 'assert'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "assert": false }
ERROR in ./node_modules/ethereumjs-util/dist.browser/object.js 12:31-48
Module not found: Error: Can't resolve 'assert' in '/Users/theanti/Downloads/front/node_modules/ethereumjs-util/dist.browser'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "assert": require.resolve("assert/") }'
- install 'assert'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "assert": false }
ERROR in ./node_modules/micro-ftch/index.js 57:15-30
Module not found: Error: Can't resolve 'http' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "http": require.resolve("stream-http") }'
- install 'stream-http'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "http": false }
ERROR in ./node_modules/micro-ftch/index.js 58:16-32
Module not found: Error: Can't resolve 'https' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "https": require.resolve("https-browserify") }'
- install 'https-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "https": false }
ERROR in ./node_modules/micro-ftch/index.js 59:15-30
Module not found: Error: Can't resolve 'zlib' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "zlib": require.resolve("browserify-zlib") }'
- install 'browserify-zlib'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "zlib": false }
ERROR in ./node_modules/micro-ftch/index.js 65:6-20
Module not found: Error: Can't resolve 'url' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "url": require.resolve("url/") }'
- install 'url'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "url": false }
ERROR in ./src/index.tsx 8:0-30
Module not found: Error: Can't resolve './styles/globals.css' in '/Users/theanti/Downloads/front/src'
ERROR in ./node_modules/cipher-base/index.js 2:16-43
Module not found: Error: Can't resolve 'stream' in '/Users/theanti/Downloads/front/node_modules/cipher-base'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "stream": require.resolve("stream-browserify") }'
- install 'stream-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "stream": false }
ERROR in ./node_modules/ethereumjs-util/dist.browser/account.js 34:31-48
Module not found: Error: Can't resolve 'assert' in '/Users/theanti/Downloads/front/node_modules/ethereumjs-util/dist.browser'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "assert": require.resolve("assert/") }'
- install 'assert'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "assert": false }
ERROR in ./node_modules/ethereumjs-util/dist.browser/address.js 12:31-48
Module not found: Error: Can't resolve 'assert' in '/Users/theanti/Downloads/front/node_modules/ethereumjs-util/dist.browser'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "assert": require.resolve("assert/") }'
- install 'assert'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "assert": false }
ERROR in ./node_modules/ethereumjs-util/dist.browser/object.js 12:31-48
Module not found: Error: Can't resolve 'assert' in '/Users/theanti/Downloads/front/node_modules/ethereumjs-util/dist.browser'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "assert": require.resolve("assert/") }'
- install 'assert'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "assert": false }
ERROR in ./node_modules/micro-ftch/index.js 57:15-30
Module not found: Error: Can't resolve 'http' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "http": require.resolve("stream-http") }'
- install 'stream-http'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "http": false }
ERROR in ./node_modules/micro-ftch/index.js 58:16-32
Module not found: Error: Can't resolve 'https' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "https": require.resolve("https-browserify") }'
- install 'https-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "https": false }
ERROR in ./node_modules/micro-ftch/index.js 59:15-30
Module not found: Error: Can't resolve 'zlib' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "zlib": require.resolve("browserify-zlib") }'
- install 'browserify-zlib'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "zlib": false }
ERROR in ./node_modules/micro-ftch/index.js 65:6-20
Module not found: Error: Can't resolve 'url' in '/Users/theanti/Downloads/front/node_modules/micro-ftch'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.
If you want to include a polyfill, you need to:
- add a fallback 'resolve.fallback: { "url": require.resolve("url/") }'
- install 'url'
If you don't want to include a polyfill, you can use an empty module like this:
resolve.fallback: { "url": false }

Hi @dedmonies - Are you using Create React App?
If you are - please follow the steps mentioned at https://portal.thirdweb.com/react/getting-started


Fix conda environment.yml of development branch

The environment in the development branch appears to be broken, from circleci:
conda env update --quiet --file environment.yml --name esmvaltool

UnsatisfiableError: The following specifications were found to be in conflict:
  - hdf5 1.8.17*
  - libnetcdf <IP_ADDRESS>* -> hdf5 1.8.18|1.8.18.*
Use "conda info <package>" to see the dependencies for each package.

Exited with code 1

I am trying to set up a new conda environment for esmvaltool. Has anyone seen the below?
conda create --name esmvaltool python=2
gives
get solving environment: /\
but then
CondaHTTPError: HTTP 000 CONNECTION FAILED for url https://repo.anaconda.com/pkgs/pro/linux-64/repodata.json.bz2
I tried again in case server was down, but keep getting error.  The install website instructions are
conda create --name esmvaltool python=2
conda env update --name esmvaltool --file ESMValTool/environment.yml
source activate esmvaltool
Thanks


[WIP] Add ACL Anthology support.

WIP addition for ACL Anthology support

Thanks @jayded! I know you are busy so I went ahead and fixed your PR + some backlogged items. feel free to reopen if I missed something


Kong Balancer timing out for a few minutes after starting

We're facing a problem with Kong 1.1.0 dbless, using declarative config. If in our config there's an upstream created, Kong will timeout for a few seconds/minutes after restarting, until it apparently stabilizes.
I ran some investigation and it seems that when we're using a database (in our case, postgres), after starting it will not try to create the balancers for all upstreams upon initialization. But on dbless mode, it will create the balancers after parsing the declarative config. Here, basically:
      ngx.timer.at(0, function()
        balancer.init()
      end)

The problem is, using more than 1 worker there seems to be some problem that makes some of the workers waiting for long times until the balancers get created. Still couldn't figure out what's the concurrency issue, but I've added some logs to investigate (they're on the attached patch, I've put them over tag 1.1.0).
So some thread or worker marks that creating[upstream.id] as true and other workers keep waiting for a long time on that wait(upstream.id) function (talking about this code), not sure why the thread actually creating the balancer is holding this and not releasing the creating state.
We can see the difference on the logs here (using tail - f error.log | grep -E "(balancer\.lua|BALANCER_DBLESS_DEBUG)"):
1 worker:
2019/04/12 14:06:21 [debug] 6827#0: *1 [lua] handler.lua:551: before(): BALANCER_DBLESS_DEBUG - calling balancer.init()
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:86: fetching upstream: 3a3f34b0-d4f8-424c-aba7-70822f46c8f0
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:742: init(): BALANCER_DBLESS_DEBUG - before creating balancer
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:363: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 1
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:368: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 2
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:377: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 3
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:385: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 4
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:390: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 5
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:112: fetching targets for upstream: 3a3f34b0-d4f8-424c-aba7-70822f46c8f0
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:401: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 6
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:409: create_balancer(): BALANCER_DBLESS_DEBUG - Marking creating with nil
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:744: init(): BALANCER_DBLESS_DEBUG - after creating balancer
2019/04/12 14:06:21 [debug] 6827#0: *2 [lua] balancer.lua:752: init(): initialized 1 balancer(s), 0 error(s)

2 workers:
2019/04/12 14:08:30 [debug] 7023#0: *2 [lua] handler.lua:551: before(): BALANCER_DBLESS_DEBUG - calling balancer.init()
2019/04/12 14:08:30 [debug] 7022#0: *1 [lua] handler.lua:551: before(): BALANCER_DBLESS_DEBUG - calling balancer.init()
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:86: fetching upstream: c81ff421-7a46-4d2d-9ce5-f560d6a4c455
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:742: init(): BALANCER_DBLESS_DEBUG - before creating balancer
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:363: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 1
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:368: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 2
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:377: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 3
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:385: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 4
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:390: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 5
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:112: fetching targets for upstream: c81ff421-7a46-4d2d-9ce5-f560d6a4c455
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:401: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 6
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:742: init(): BALANCER_DBLESS_DEBUG - before creating balancer
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:363: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 1
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:368: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 2
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:377: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 3
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:385: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 4
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:390: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 5
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:401: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 6
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:409: create_balancer(): BALANCER_DBLESS_DEBUG - Marking creating with nil
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:744: init(): BALANCER_DBLESS_DEBUG - after creating balancer
2019/04/12 14:08:31 [debug] 7023#0: *3 [lua] balancer.lua:752: init(): initialized 1 balancer(s), 0 error(s)
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:363: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 1
2019/04/12 14:08:31 [debug] 7022#0: *7 [lua] balancer.lua:368: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 2
2019/04/12 14:08:31 [debug] 7023#0: *35 [lua] balancer.lua:363: create_balancer(): BALANCER_DBLESS_DEBUG - creating balancer - step 1
2019/04/12 14:08:31 [debug] 7023#0: *35 [lua] balancer.lua:112: fetching targets for upstream: c81ff421-7a46-4d2d-9ce5-f560d6a4c455
2019/04/12 14:08:31 [debug] 7023#0: *35 [lua] balancer.lua:112: fetching targets for upstream: c81ff421-7a46-4d2d-9ce5-f560d6a4c455
2019/04/12 14:09:01 [crit] 7022#0: *7 [lua] balancer.lua:622: on_upstream_event(): failed creating balancer for buckets: timeout waiting for balancer for c81ff421-7a46-4d2d-9ce5-f560d6a4c455, context: ngx.timer
2019/04/12 14:09:01 [error] 7022#0: *7 [lua] balancer.lua:591: on_target_event(): target create: balancer not found for buckets, context: ngx.timer
2019/04/12 14:09:01 [error] 7022#0: *7 [lua] balancer.lua:591: on_target_event(): target create: balancer not found for buckets, context: ngx.timer
2019/04/12 14:09:01 [debug] 7022#0: *7 [lua] balancer.lua:409: create_balancer(): BALANCER_DBLESS_DEBUG - Marking creating with nil
2019/04/12 14:09:01 [debug] 7022#0: *7 [lua] balancer.lua:744: init(): BALANCER_DBLESS_DEBUG - after creating balancer
2019/04/12 14:09:01 [debug] 7022#0: *7 [lua] balancer.lua:752: init(): initialized 1 balancer(s), 0 error(s)

We can see that second worker (PID 7022) trying to create the balancer will get stuck for about 30s. All the requests going to that thread for the upstream will take a long to return, or timeout. With more workers (e.g., 4) the requests to that service will certainly timeout for a long time (minutes) until it finishes creating everything.
Steps To Reproduce

use attached kong.yml as declarative config. The targets won't be accessible, but the problem can be reproduced by just starting kong with that config.
use more than 1 worker setting nginx_worker_processes on kong.conf
start kong and watch logs
also, could apply the attached patch to see the logs I mention above
with several workers, try to request:

http localhost:8000/v1/f174909b-40f1-4d71-ae5f-4fa86ff2b4ab.json

... it will certainly timeout (30s) the request in the first minutes after Kong started.
Additional Details & Logs

Kong version: 1.1.0
Kong configuration: at the end of bug (attachments section)
Operating system: Centos 7 (on vagrant VM)

Attachments:
0001-Adding-logs-to-investigate-balancer-issue-with-dbles.patch
From a602ebee3930b14b01fb01e37a37d824dafb5079 Mon Sep 17 00:00:00 2001
From: Daniel Liberman<EMAIL_ADDRESS>Date: Fri, 12 Apr 2019 11:39:52 -0300
Subject: [PATCH] Adding logs to investigate balancer issue with dbless mode

---
 kong/runloop/balancer.lua | 9 +++++++++
 kong/runloop/handler.lua  | 1 +
 2 files changed, 10 insertions(+)

diff --git a/kong/runloop/balancer.lua b/kong/runloop/balancer.lua
index 00ab5daf..14beb920 100644
--- a/kong/runloop/balancer.lua
+++ b/kong/runloop/balancer.lua
@@ -360,10 +360,12 @@ do
   -- @return The new balancer object, or nil+error
   create_balancer = function(upstream, recreate, history, start)

+    log(DEBUG, "BALANCER_DBLESS_DEBUG - creating balancer - step 1")
     if balancers[upstream.id] and not recreate then
       return balancers[upstream.id]
     end

+    log(DEBUG, "BALANCER_DBLESS_DEBUG - creating balancer - step 2")
     if creating[upstream.id] then
       local ok = wait(upstream.id)
       if not ok then
@@ -372,6 +374,7 @@ do
       return balancers[upstream.id]
     end

+    log(DEBUG, "BALANCER_DBLESS_DEBUG - creating balancer - step 3")
     creating[upstream.id] = true

     local balancer, err = ring_balancer.new({
@@ -379,10 +382,12 @@ do
         dns = dns_client,
       })

+    log(DEBUG, "BALANCER_DBLESS_DEBUG - creating balancer - step 4")
     if not balancer then
       return nil, err
     end

+    log(DEBUG, "BALANCER_DBLESS_DEBUG - creating balancer - step 5")
     target_histories[balancer] = {}

     if not history then
@@ -393,6 +398,7 @@ do
       start = 1
     end

+    log(DEBUG, "BALANCER_DBLESS_DEBUG - creating balancer - step 6")
     apply_history(balancer, history, start)

     create_healthchecker(balancer, upstream)
@@ -400,6 +406,7 @@ do
     -- only make the new balancer available for other requests after it
     -- is fully set up.
     balancers[upstream.id] = balancer
+    log(DEBUG, "BALANCER_DBLESS_DEBUG - Marking creating with nil")

     creating[upstream.id] = nil

@@ -732,7 +739,9 @@ local function init()
   local oks, errs = 0, 0
   for name, id in pairs(upstreams) do
     local upstream = get_upstream_by_id(id)
+    log(DEBUG, "BALANCER_DBLESS_DEBUG - before creating balancer")
     local ok, err = create_balancer(upstream)
+    log(DEBUG, "BALANCER_DBLESS_DEBUG - after creating balancer")
     if ok ~= nil then
       oks = oks + 1
     else
diff --git a/kong/runloop/handler.lua b/kong/runloop/handler.lua
index 9c9699f5..ba279da6 100644
--- a/kong/runloop/handler.lua
+++ b/kong/runloop/handler.lua
@@ -548,6 +548,7 @@ return {

       -- initialize balancers for active healthchecks
+      log(DEBUG, "BALANCER_DBLESS_DEBUG - calling balancer.init()")
       ngx.timer.at(0, function()
         balancer.init()
       end)
--
2.17.1

kong.yml
_format_version: '1.1'

services:
- name: buckets
  url: http://buckets/
  routes:
  - name: root
    paths:
    - "/"

upstreams:
- name: buckets
  healthchecks:
    active:
      http_path: "/empty.json"
      unhealthy:
        interval: 5
      healthy:
        successes: 2
        interval: 0
        http_statuses:
        - 200
        - 301
        - 302
    passive:
      healthy:
        successes: 2
        http_statuses:
        - 200
        - 301
        - 302
      unhealthy:
        tcp_failures: 2
        timeouts: 2
        http_failures: 2
        http_statuses:
        - 404
        - 429
        - 500
        - 501
        - 502
        - 503
  targets:
  - target: circuit-breakers-test2.s3-website.us-east-2.amazonaws.com:80
    weight: 1
  - target: circuit-breakers-test1.s3-website-sa-east-1.amazonaws.com:80
    weight: 1000

kong config
{"plugins":{"enabled_in_cluster":[],"available_on_server":{"correlation-id":true,"pre-function":true,"request-transformer-advanced":true,"cors":true,"rate-limiting":true,"loggly":true,"ifood-kong-jwt-merchants-plugin":true,"hmac-auth":true,"zipkin":true,"bot-detection":true,"ifood-kong-remote-addr-plugin":true,"azure-functions":true,"request-transformer":true,"oauth2":true,"response-transformer":true,"ip-restriction":true,"statsd":true,"jwt":true,"basic-auth":true,"key-auth":true,"ifood-kong-prometheus-plugin":true,"ifood-kong-rbl-plugin":true,"http-log":true,"sample-cache-plugin":true,"generic-request-transformer":true,"ifood-kong-jwt-public-keys-plugin":true,"datadog":true,"tcp-log":true,"ifood-kong-jwt-plugin":true,"post-function":true,"prometheus":true,"acl":true,"kubernetes-sidecar-injector":true,"request-size-limiting":true,"response-ratelimiting":true,"udp-log":true,"file-log":true,"aws-lambda":true,"syslog":true,"ldap-auth":true,"request-termination":true}},"tagline":"Welcome to kong","configuration":{"plugins":["bundled","ifood-kong-jwt-merchants-plugin","ifood-kong-jwt-plugin","ifood-kong-rbl-plugin","ifood-kong-remote-addr-plugin","generic-request-transformer","request-transformer-advanced","sample-cache-plugin","ifood-kong-jwt-public-keys-plugin","ifood-kong-prometheus-plugin"],"client_ssl":false,"proxy_access_log":"\/vagrant\/kong-ce\/access.log","trusted_ips":["<IP_ADDRESS>\/0"],"prefix":"\/usr\/local\/kong","loaded_plugins":{"correlation-id":true,"pre-function":true,"request-transformer-advanced":true,"cors":true,"rate-limiting":true,"loggly":true,"ifood-kong-jwt-merchants-plugin":true,"hmac-auth":true,"zipkin":true,"bot-detection":true,"ifood-kong-remote-addr-plugin":true,"azure-functions":true,"request-transformer":true,"oauth2":true,"response-transformer":true,"ip-restriction":true,"statsd":true,"jwt":true,"basic-auth":true,"key-auth":true,"prometheus":true,"ldap-auth":true,"http-log":true,"sample-cache-plugin":true,"syslog":true,"ifood-kong-jwt-public-keys-plugin":true,"datadog":true,"ifood-kong-jwt-plugin":true,"ifood-kong-prometheus-plugin":true,"post-function":true,"file-log":true,"acl":true,"kubernetes-sidecar-injector":true,"request-size-limiting":true,"response-ratelimiting":true,"udp-log":true,"generic-request-transformer":true,"aws-lambda":true,"ifood-kong-rbl-plugin":true,"tcp-log":true,"request-termination":true},"cassandra_username":"kong","ssl_cert_key":"\/usr\/local\/kong\/ssl\/kong-default.key","dns_resolver":{},"pg_user":"kong","mem_cache_size":"20m","cassandra_data_centers":["dc1:2","dc2:3"],"nginx_admin_directives":{},"nginx_http_directives":[{"value":"prometheus_metrics 5m","name":"lua_shared_dict"}],"pg_host":"<IP_ADDRESS>","nginx_acc_logs":"\/usr\/local\/kong\/logs\/access.log","proxy_listen":["<IP_ADDRESS>:8000","<IP_ADDRESS>:8443 ssl"],"declarative_config":"\/etc\/kong\/kong.yml","client_ssl_cert_default":"\/usr\/local\/kong\/ssl\/kong-default.crt","ssl_cert_key_default":"\/usr\/local\/kong\/ssl\/kong-default.key","db_update_frequency":5,"db_update_propagation":0,"stream_listen":["off"],"nginx_err_logs":"\/usr\/local\/kong\/logs\/error.log","cassandra_port":9042,"dns_order":["LAST","SRV","A","CNAME"],"dns_error_ttl":1,"headers":["server_tokens","latency_tokens"],"dns_valid_ttl":120,"cassandra_lb_policy":"RequestRoundRobin","nginx_optimizations":true,"origins":{},"database":"off","pg_database":"kong110_dbless","nginx_worker_processes":"2","lua_package_cpath":"","admin_acc_logs":"\/usr\/local\/kong\/logs\/admin_access.log","lua_package_path":".\/?.lua;.\/?\/init.lua;","nginx_pid":"\/usr\/local\/kong\/pids\/nginx.pid","upstream_keepalive":60,"cassandra_contact_points":["<IP_ADDRESS>"],"db_cache_ttl":0,"admin_access_log":"\/vagrant\/kong-ce\/admin_access.log","nginx_conf":"\/usr\/local\/kong\/nginx.conf","nginx_stream_directives":{},"proxy_listeners":[{"transparent":false,"ssl":false,"ip":"<IP_ADDRESS>","proxy_protocol":false,"port":8000,"http2":false,"listener":"<IP_ADDRESS>:8000"},{"transparent":false,"ssl":true,"ip":"<IP_ADDRESS>","proxy_protocol":false,"port":8443,"http2":false,"listener":"<IP_ADDRESS>:8443 ssl"}],"proxy_ssl_enabled":true,"cassandra_repl_factor":1,"dns_stale_ttl":4,"enabled_headers":{"latency_tokens":true,"X-Kong-Proxy-Latency":true,"Via":true,"server_tokens":true,"Server":true,"X-Kong-Upstream-Latency":true,"X-Kong-Upstream-Status":false},"admin_ssl_cert_default":"\/usr\/local\/kong\/ssl\/admin-kong-default.crt","ssl_ciphers":"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256","db_resurrect_ttl":30,"pg_timeout":60000,"cassandra_consistency":"ONE","client_max_body_size":"0","admin_error_log":"\/vagrant\/kong-ce\/error.log","pg_ssl_verify":false,"dns_not_found_ttl":30,"pg_ssl":false,"admin_ssl_enabled":false,"error_default_type":"text\/plain","cassandra_repl_strategy":"SimpleStrategy","real_ip_header":"X-Real-IP","log_level":"debug","nginx_sproxy_directives":{},"ssl_cipher_suite":"modern","nginx_kong_conf":"\/usr\/local\/kong\/nginx-kong.conf","cassandra_schema_consensus_timeout":60000,"dns_hostsfile":"\/etc\/hosts","admin_listeners":[{"transparent":false,"ssl":false,"ip":"<IP_ADDRESS>","proxy_protocol":false,"port":8001,"http2":false,"listener":"<IP_ADDRESS>:8001"}],"nginx_proxy_directives":{},"ssl_cert":"\/usr\/local\/kong\/ssl\/kong-default.crt","cassandra_timeout":60000,"admin_ssl_cert_key_default":"\/usr\/local\/kong\/ssl\/admin-kong-default.key","cassandra_ssl_verify":false,"dns_no_sync":false,"lua_ssl_verify_depth":1,"real_ip_recursive":"on","proxy_error_log":"\/vagrant\/kong-ce\/error.log","client_ssl_cert_key_default":"\/usr\/local\/kong\/ssl\/kong-default.key","nginx_daemon":"on","anonymous_reports":false,"kong_env":"\/usr\/local\/kong\/.kong_env","stream_listeners":{},"pg_port":5432,"nginx_kong_stream_conf":"\/usr\/local\/kong\/nginx-kong-stream.conf","client_body_buffer_size":"8k","ssl_preread_enabled":true,"lua_socket_pool_size":30,"ssl_cert_csr_default":"\/usr\/local\/kong\/ssl\/kong-default.csr","cassandra_keyspace":"kong","ssl_cert_default":"\/usr\/local\/kong\/ssl\/kong-default.crt","cassandra_ssl":false,"admin_listen":["<IP_ADDRESS>:8001"]},"version":"1.1.0","node_id":"4613561d-5c63-4ae3-93c0-396af421baf6","lua_version":"LuaJIT 2.1.0-beta3","prng_seeds":{"pid: 7023":285413248142,"pid: 7014":209769119018,"pid: 7022":222321021771},"timers":{"pending":2,"running":0},"hostname":"localhost.localdomain"}

@dliberman thanks for the detail report! I'll look into reproducing it.

Hi @dliberman, I have a PR with a proposed fix open here: https://github.com/Kong/kong/pull/4534

@hishamhm, I just tested and it seems to be working fine with your changes. :)
After a little more investigation I came to another small bug. I found out I couldn't see any log messages when it had DB mode OFF. It was a small issue on load_declarative_config() (here) where it tried to load it regardless of database was set to off or not, if you passed the declarative file name on kong.conf. But I also see on master that you've fixed it already as well.
Thanks a lot for working on it!
CC: @UkiahSmith @carnei-ro

Awesome, thanks for the feedback @dliberman !


Add upgrade guide for v12

/test mini

Test passed, preview looks fine to me:
https://cupy--7430.org.readthedocs.build/en/7430/upgrade.html#cupy-v12


Add export for children helper in SSR

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.588%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1113

Relevant Lines:
1188

💛  - Coveralls

Thank you


ujust bluefin-cli doesn't reflect current login shell

Describe the bug
i changed the default shell from bash to fish using the configure-shell ujust but the change is not reflected in the ujust bluefin-cli.

What did you expect to happen?
I expected the shell to change to fish in ujust bluefin-cli.
Output of rpm-ostree status
vishwas@vishwaspc ~> rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 3min 35s ago
Deployments:
  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable
                   Digest: sha256:d48d66349a69169f7dc9aa69ea16c0c250ec3c3b992fef1a42a35e7abc7d8a4b
                  Version: 40.20240721.0 (2024-07-21T14:34:24Z)
                     Diff: 7 removed

● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable
                   Digest: sha256:d48d66349a69169f7dc9aa69ea16c0c250ec3c3b992fef1a42a35e7abc7d8a4b
                  Version: 40.20240721.0 (2024-07-21T14:34:24Z)
          LayeredPackages: okular

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable
                   Digest: sha256:2b637cdec3398cfe1226a33576add5bf528fec3a3f6c45b233a70fa838e767b9
                  Version: 40.20240721.0 (2024-07-21T05:09:08Z)

Output of groups
vishwas@vishwaspc ~> groups
vishwas wheel incus-admin lxd docker libvirt

Extra information or context
No response

my bad guys i had to logout and login


allow comment line to certain functions

I have set removeComments as true in my config file. So it will remove all comment lines from typescript to javascript file. I need to allow certain comment line for some functions and other need to be removed.
// allow comment
/* istanbul ignore if  */
if (condition) {
}
// remove comment

is there any option available in gulp-typescript for this scenario?

At the moment there is not such option. I cannot add such option if it is not supported in TypeScript, so you should open a request there. But it might be easier to turn removeComments off.


[WIP] [AMD-120] Neo4j Publisher to support desired state of relation

Summary of Changes
Include a summary of changes then remove this line
Tests
What tests did you add or modify and why? If no tests were added or modified, explain why. Remove this line
Documentation
What documentation did you add or modify and why? Add any relevant links then remove this line
CheckList
Make sure you have checked all steps below to ensure a timely review.

[ ] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[ ] PR includes a summary of changes.
[ ] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

[ ] PR passes make test
[ ] I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message"

Codecov Report

Merging #69 into master will increase coverage by 0.45%.
The diff coverage is 81.81%.

@@            Coverage Diff             @@
##           master      #69      +/-   ##
==========================================
+ Coverage   82.99%   83.44%   +0.45%
==========================================
  Files          53       53
  Lines        2499     2435      -64
  Branches      247      239       -8
==========================================
- Hits         2074     2032      -42
+ Misses        344      325      -19
+ Partials       81       78       -3

Impacted Files
Coverage Δ

databuilder/publisher/neo4j_csv_publisher.py
84.12% <81.39%> (-2.01%)
:arrow_down:

databuilder/publisher/neo4j_preprocessor.py
83.33% <83.33%> (ø)

...tabuilder/extractor/bigquery_metadata_extractor.py
94.89% <0%> (-1.4%)
:arrow_down:

databuilder/extractor/kafka_source_extractor.py

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f73c812...9ec84e7. Read the comment docs.

Did a first pass and left some comments

[AMD-120] is a our jira :) I think we should file an issue instead.
And preprocessor is only neo4j and relation. Should we be able to support node preprocessor?

Removed [AMD-120] header. :)
I think we can introduce node preprocessor later on when needed with almost exactly same pattern. Thought about adding it, but didn't want to add dead code w/o concrete use case.


Not reading last column

Hi,
I'm using the following code to read a excel file, but it's not reading the last column:
`public static DataSet ReadExcel2003(Stream stream)
{
DataSet result = new DataSet();
var tmpFile = Path.GetTempPath() + Guid.NewGuid().ToString() + ".xls";
        FileStream fileStream = File.Create(tmpFile, (int)stream.Length);

        byte[] bytesInStream = new byte[stream.Length];
        stream.Read(bytesInStream, 0, bytesInStream.Length);
        fileStream.Write(bytesInStream, 0, bytesInStream.Length);
        fileStream.Close();
        stream.Close();

		Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("pt-BR");
        using (IExcelDataReader excelReader = ExcelReaderFactory.CreateBinaryReader(File.Open(tmpFile, FileMode.Open, FileAccess.Read),ReadOption.Strict))
        {
            result = excelReader.AsDataSet();
        }

        File.Delete(tmpFile);

        return result;
    }

`
I attached the file I'm trying to read, the yellow cells are not being reading.
6031b574-9284-4129-af7f-aa9fa5d50806.zip

No problems reading both:
result.Tables[0].Rows[1][5] as string
result.Tables[0].Rows[2][5] as double

Thi is weird, I'm getting this:

  result.Tables[0].Rows[1][5]	'result.Tables[0].Rows[1][5]' threw an exception of type 'System.IndexOutOfRangeException'	object {System.IndexOutOfRangeException}

my 'result' does not have index 5

Sorry about it...
http://i67.tinypic.com/33p4zuu.png

@wizardgsz  I'm not able to open your attachment

Can you please share your code?   @wizardgsz

I found the issue, the years are stored as text. Looks like thats the problem. @wizardgsz  Do you know how to handle it?
Thanks in advance

Yeah, ur right but I'm using the latest trunk release (develop) for .Net 2.0 and not a "branched/modified" build.
I'm wondering why you had problems reading last column (IndexOutOfRangeException): did you run TestApp also?

@wizardgsz Yes, I ran TestApp look:


Add ck::wait_any and ck::wait_all

These are mechanisms by wait to wait on multiple futures simultaneously without introducing a busy-loop in the user's code. Most critically, perhaps, this represents a steps towards bringing our futures on par with those of other runtimes. The ability to retrieve the first value available among multiple futures can be used as a mechanism for implementing many higher-level constructs (e.g. something analogous to SDAG's overlap).

This is dependent on PR#3230, which should be merged first; this PR will be rebased onto master once that has occurred. (Is there a better way to express this relationship?)

This is dependent on PR#3230, which should be merged first; this PR will be rebased onto master once that has occurred. (Is there a better way to express this relationship?)

This is dependent on PR#3230, which should be merged first; this PR will be rebased onto master once that has occurred. (Is there a better way to express this relationship?)

What you're doing is right, GitHub will automatically change the target branch to master once the branch this depends on is merged.

This is dependent on PR#3230, which should be merged first; this PR will be rebased onto master once that has occurred. (Is there a better way to express this relationship?)

What you're doing is right, GitHub will automatically change the target branch to master once the branch this depends on is merged.

MPI has a "Waitsome" which returns however many requests have already completed. That might be useful for futures users as well.

MPI has a "Waitsome" which returns however many requests have already completed. That might be useful for futures users as well.

MPI has a "Waitsome" which returns however many requests have already completed. That might be useful for futures users as well.
That would be fairly straightforward to add. I can have a preliminary implementation by this evening, and include it in this PR or separately.

MPI has a "Waitsome" which returns however many requests have already completed. That might be useful for futures users as well.
That would be fairly straightforward to add. I can have a preliminary implementation by this evening, and include it in this PR or separately.

Can you add a section to the futures part fo the manual on these? Otherwise looks good

Added a little table and pointer to the examples.

LGTM. Moving forward, is CkFutureID something we'd want to convert to a 64bit ID?

Eventually, yes, it's not difficult to exceed its numerical limits at this current time. However, it currently maps to a refnum so enabling a 64-bit ID requires some refactoring of the FutureBOC chare-group.


New version: TravisLane.SteamArtManager version 2.0.0

Pull request has been created with Komac v1.11.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

/AzurePipelines run


Redis is not running

报以下错误，但是我单独用php文件链接redis，是成功的
The compiled services & packages files have been removed.
Cache cleared successfully.
Route cache cleared!
Configuration cache cleared!
Compiled views cleared!

Welcome to Fixhub

Redis is not running
Fixhub cannot be installed. Please review the errors above before continuing.

.env文件 REDIS_PASSWORD值是什么？

REDIS_HOST=<IP_ADDRESS>
28
REDIS_PORT=6379
29
REDIS_DATABASE=0
30
REDIS_PASSWORD=

解决了..谢谢

socket启动不起来0.0


PV gets created, but fails to attach.

It's me again...
I have created a PVC and the default storage class is "longhorn".
The PV gets successfully created and I can see it in the UI, but it looks like this:

As you can see the PVs are attached to the right Pods, but the status is "Detached". Therefore the node names under the pod names are missing.
The postgres pod shows this:
Events:
  Type     Reason              Age                  From                              Message
  ----     ------              ----                 ----                              -------
  Normal   Scheduled           9m9s                 default-scheduler                 Successfully assigned nextcloud/postgres-7fb7587bcb-j78ws to <<node>>
  Warning  FailedAttachVolume  37s (x5 over 8m45s)  attachdetach-controller           AttachVolume.Attach failed for volume "pvc-6ead7550-9e2f-11e9-8c96-d094661b9f26" : rpc error: code = Internal desc = Get http://longhorn-backend:9500/v1/volumes/pvc-6ead7550-9e2f-11e9-8c96-d094661b9f26: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
  Warning  FailedMount         19s (x4 over 7m6s)   kubelet, <<node>>                 Unable to mount volumes for pod "postgres-7fb7587bcb-j78ws_nextcloud(71490a49-9e31-11e9-a97c-d4ae52ad4f13)": timeout expired waiting for volumes to attach or mount for pod "nextcloud"/"postgres-7fb7587bcb-j78ws". list of unmounted volumes=[postgres-volume]. list of unattached volumes=[postgres-volume default-token-vshk7]
  Warning  FailedAttachVolume  3s (x4 over 7s)      attachdetach-controller           AttachVolume.Attach failed for volume "pvc-acf67468-9e32-11e9-a97c-d4ae52ad4f13" : rpc error: code = Internal desc = Get http://longhorn-backend:9500/v1/volumes/pvc-acf67468-9e32-11e9-a97c-d4ae52ad4f13: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

The relevant ouput of kubectl logs longhorn-manager-56fwx is this I guess:
E0704 08:17:08.157925       1 kubernetes_controller.go:193] kubernetes-controller: fail to sync pvc-1bfe7936-9e34-11e9-8c96-d094661b9f26: Operation cannot be fulfilled on volumes.longhorn.rancher.io "pvc-1bfe7936-9e34-11e9-8c96-d094661b9f26": the object has been modified; please apply your changes to the latest version and try again
time="2019-07-04T08:17:08Z" level=warning msg="Dropping Persistent Volume pvc-1bfe7936-9e34-11e9-8c96-d094661b9f26 out of the queue: kubernetes-controller: fail to sync pvc-1bfe7936-9e34-11e9-8c96-d094661b9f26: Operation cannot be fulfilled on volumes.longhorn.rancher.io \"pvc-1bfe7936-9e34-11e9-8c96-d094661b9f26\": the object has been modified; please apply your changes to the latest version and try again"
time="2019-07-04T08:17:21Z" level=info msg="Event(v1.ObjectReference{Kind:\"Volume\", Namespace:\"longhorn-system\", Name:\"pvc-1c467778-9e34-11e9-8c96-d094661b9f26\", UID:\"2436f386-9e34-11e9-a97c-d4ae52ad4f13\", APIVersion:\"longhorn.rancher.io/v1alpha1\", ResourceVersion:\"59570044\", FieldPath:\"\"}): type: 'Normal' reason: 'Start' Persistent Volume pvc-1c467778-9e34-11e9-8c96-d094661b9f26 started to use/reuse Longhorn volume pvc-1c467778-9e34-11e9-8c96-d094661b9f26"
E0704 08:17:21.619806       1 kubernetes_controller.go:193] kubernetes-controller: fail to sync pvc-1c467778-9e34-11e9-8c96-d094661b9f26: Operation cannot be fulfilled on volumes.longhorn.rancher.io "pvc-1c467778-9e34-11e9-8c96-d094661b9f26": the object has been modified; please apply your changes to the latest version and try again
time="2019-07-04T08:17:21Z" level=warning msg="Dropping Persistent Volume pvc-1c467778-9e34-11e9-8c96-d094661b9f26 out of the queue: kubernetes-controller: fail to sync pvc-1c467778-9e34-11e9-8c96-d094661b9f26: Operation cannot be fulfilled on volumes.longhorn.rancher.io \"pvc-1c467778-9e34-11e9-8c96-d094661b9f26\": the object has been modified; please apply your changes to the latest version and try again"

I have no idea what to do with this information. The last days everything worked fine.

The error message you saw shouldn't cause this. Any more logs around the time when this happened?

Yes, the csi-attacher logs like crazy since days:
I0708 08:25:01.348802       1 controller.go:167] Started VA processing "csi-8d148bacf36e1ac33584dc342111ef195b82bcbd17627a77931793510274f6ea"
I0708 08:25:01.348814       1 csi_handler.go:85] CSIHandler: processing VA "csi-8d148bacf36e1ac33584dc342111ef195b82bcbd17627a77931793510274f6ea"
I0708 08:25:01.348823       1 csi_handler.go:112] Attaching "csi-8d148bacf36e1ac33584dc342111ef195b82bcbd17627a77931793510274f6ea"
I0708 08:25:01.348831       1 csi_handler.go:217] Starting attach operation for "csi-8d148bacf36e1ac33584dc342111ef195b82bcbd17627a77931793510274f6ea"
I0708 08:25:01.348844       1 csi_handler.go:323] Saving attach error to "csi-8d148bacf36e1ac33584dc342111ef195b82bcbd17627a77931793510274f6ea"
I0708 08:25:01.541771       1 request.go:530] Throttling request took 1.994500263s, request: PUT:https://<IP_ADDRESS>:443/apis/storage.k8s.io/v1beta1/volumeattachments/csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f
I0708 08:25:01.549199       1 csi_handler.go:333] Saved attach error to "csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f"
I0708 08:25:01.549239       1 csi_handler.go:95] Error processing "csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f": failed to attach: persistentvolume "pvc-e377a7e1-9e29-11e9-a97c-d4ae52ad4f13" not found
I0708 08:25:01.549356       1 controller.go:167] Started VA processing "csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f"
I0708 08:25:01.549387       1 csi_handler.go:85] CSIHandler: processing VA "csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f"
I0708 08:25:01.549402       1 csi_handler.go:112] Attaching "csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f"
I0708 08:25:01.549419       1 csi_handler.go:217] Starting attach operation for "csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f"
I0708 08:25:01.549449       1 csi_handler.go:323] Saving attach error to "csi-d36d00a15c3f99806f2ab2d46604c9811c9422bc8b859fba85e01864309b304f"
I0708 08:25:01.741746       1 request.go:530] Throttling request took 1.994388695s, request: PUT:https://<IP_ADDRESS>:443/apis/storage.k8s.io/v1beta1/volumeattachments/csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6
I0708 08:25:01.748458       1 csi_handler.go:333] Saved attach error to "csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6"
I0708 08:25:01.748484       1 csi_handler.go:95] Error processing "csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6": failed to attach: persistentvolume "pvc-4991fac9-9e2c-11e9-8c96-d094661b9f26" not found
I0708 08:25:01.748533       1 controller.go:167] Started VA processing "csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6"
I0708 08:25:01.748544       1 csi_handler.go:85] CSIHandler: processing VA "csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6"
I0708 08:25:01.748555       1 csi_handler.go:112] Attaching "csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6"
I0708 08:25:01.748564       1 csi_handler.go:217] Starting attach operation for "csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6"
I0708 08:25:01.748579       1 csi_handler.go:323] Saving attach error to "csi-c70200ad0cdd47ed1f12cf86cfba2b3ce7812b7beb2b9ec9b76b11eca77c8fb6"
I0708 08:25:01.941735       1 request.go:530] Throttling request took 1.993794361s, request: PUT:https://<IP_ADDRESS>:443/apis/storage.k8s.io/v1beta1/volumeattachments/csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a
I0708 08:25:01.948228       1 csi_handler.go:333] Saved attach error to "csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a"
I0708 08:25:01.948252       1 csi_handler.go:95] Error processing "csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a": failed to attach: persistentvolume "pvc-acf67468-9e32-11e9-a97c-d4ae52ad4f13" not found
I0708 08:25:01.948326       1 controller.go:167] Started VA processing "csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a"
I0708 08:25:01.948345       1 csi_handler.go:85] CSIHandler: processing VA "csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a"
I0708 08:25:01.948362       1 csi_handler.go:112] Attaching "csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a"
I0708 08:25:01.948377       1 csi_handler.go:217] Starting attach operation for "csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a"
I0708 08:25:01.948400       1 csi_handler.go:323] Saving attach error to "csi-9736cf778e7e22f2aac18adbf60494ce7e63ae411346a2e71857b215c530055a"
I0708 08:25:02.141804       1 request.go:530] Throttling request took 1.986992251s, request: PUT:https://<IP_ADDRESS>:443/apis/storage.k8s.io/v1beta1/volumeattachments/csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a
I0708 08:25:02.148362       1 csi_handler.go:333] Saved attach error to "csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a"
I0708 08:25:02.148393       1 csi_handler.go:95] Error processing "csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a": failed to attach: persistentvolume "pvc-6ead7550-9e2f-11e9-8c96-d094661b9f26" not found
I0708 08:25:02.148571       1 controller.go:167] Started VA processing "csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a"
I0708 08:25:02.148595       1 csi_handler.go:85] CSIHandler: processing VA "csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a"
I0708 08:25:02.148609       1 csi_handler.go:112] Attaching "csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a"
I0708 08:25:02.148622       1 csi_handler.go:217] Starting attach operation for "csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a"
I0708 08:25:02.148647       1 csi_handler.go:323] Saving attach error to "csi-d4fce31bba4d05b8ae24173e1615040b302370c3c9c49b6415b0862b44e90f8a"

Apparently it tries to attach not existing volumes.
I must admit that I manually removed volumes before with kubectl edit pv <pv-name> and removed the finalizers, because they were stuck in Terminating mode.

I have restarted a few longhorn pods and now the error from the pod is a little bit different:
Events:
  Type     Reason       Age                   From                              Message
  ----     ------       ----                  ----                              -------
  Normal   Scheduled    9m27s                 default-scheduler                 Successfully assigned verdaccio/verdaccio-97b5fdbf5-xvjrv to <<node>>
  Warning  FailedMount  108s (x4 over 7m54s)  kubelet, <<node>>       MountVolume.MountDevice failed for volume "pvc-9cda55db-8474-11e9-92f8-d094661b9f26" : rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /var/lib/kubelet/plugins/io.rancher.longhorn/csi.sock: connect: connection refused"
  Warning  FailedMount  33s (x4 over 7m24s)   kubelet, <<node>>  Unable to mount volumes for pod "verdaccio-97b5fdbf5-xvjrv_verdaccio(3c9451c1-a174-11e9-a97c-d4ae52ad4f13)": timeout expired waiting for volumes to attach or mount for pod "verdaccio"/"verdaccio-97b5fdbf5-xvjrv". list of unmounted volumes=[storage]. list of unattached volumes=[storage default-token-qp8r5]

It looks like it cannot connect to longhorn?

So the csi-provisioner is printing on repeat:
I0708 11:59:31.711232       1 controller.go:134] Connecting to /var/lib/kubelet/plugins/io.rancher.longhorn/csi.sock
I0708 11:59:31.711450       1 controller.go:161] Still trying, connection is CONNECTING
I0708 11:59:31.711696       1 controller.go:161] Still trying, connection is TRANSIENT_FAILURE
I0708 11:59:32.711778       1 controller.go:161] Still trying, connection is CONNECTING
I0708 11:59:32.711851       1 controller.go:161] Still trying, connection is TRANSIENT_FAILURE
I0708 11:59:33.767294       1 controller.go:161] Still trying, connection is TRANSIENT_FAILURE
I0708 11:59:34.700820       1 controller.go:161] Still trying, connection is CONNECTING
I0708 11:59:35.857071       1 controller.go:161] Still trying, connection is TRANSIENT_FAILURE
I0708 11:59:36.904817       1 controller.go:161] Still trying, connection is CONNECTING
I0708 11:59:37.706270       1 controller.go:161] Still trying, connection is CONNECTING
I0708 11:59:38.866753       1 controller.go:161] Still trying, connection is CONNECTING
I0708 11:59:39.943687       1 controller.go:161] Still trying, connection is TRANSIENT_FAILURE
I0708 11:59:40.838046       1 controller.go:161] Still trying, connection is TRANSIENT_FAILURE
I0708 11:59:41.703408       1 controller.go:161] Still trying, connection is CONNECTING
I0708 11:59:41.711435       1 controller.go:154] Connection timed out

@itmuckel yeah, the CSI driver plugin is unable to communicate with Longhorn. Can you check kubectl -n longhorn-system get pod to see if Longhorn driver has been deployed successfully?

I was having the same issue. After my upgrade running that command I got back the following pods:
NAME                                        READY   STATUS    RESTARTS   AGE
csi-attacher-9df5cfb99-mm5x5                1/1     Running   10         21d
csi-attacher-9df5cfb99-srsfh                1/1     Running   18         21d
csi-attacher-9df5cfb99-w5894                1/1     Running   11         21d
csi-provisioner-5bd8d7cb74-6jptd            1/1     Running   9          21d
csi-provisioner-5bd8d7cb74-lhg2f            1/1     Running   11         21d
csi-provisioner-5bd8d7cb74-w68fb            1/1     Running   13         21d
engine-image-ei-3827e67c-5s8k7              1/1     Running   0          21d
engine-image-ei-3827e67c-ct28s              1/1     Running   0          21d
engine-image-ei-3827e67c-vn7gp              1/1     Running   0          21d
engine-image-ei-7c102650-4pdkf              1/1     Running   0          46d
engine-image-ei-7c102650-5kglk              1/1     Running   0          46d
engine-image-ei-7c102650-t85bm              1/1     Running   0          46d
instance-manager-e-6420d259                 1/1     Running   1          21d
instance-manager-e-7f741021                 1/1     Running   1          21d
instance-manager-e-9e5fbedc                 1/1     Running   1          21d
instance-manager-e-acc3c104                 1/1     Running   1          46d
instance-manager-e-b0ec5d6c                 1/1     Running   1          46d
instance-manager-e-d8b62452                 1/1     Running   1          46d
instance-manager-r-02bd7414                 1/1     Running   1          21d
instance-manager-r-36e46e22                 1/1     Running   1          21d
instance-manager-r-4ebb5140                 1/1     Running   1          46d
instance-manager-r-6fe53e05                 1/1     Running   1          46d
instance-manager-r-a45dd86d                 1/1     Running   1          46d
instance-manager-r-bea68673                 1/1     Running   1          21d
longhorn-csi-plugin-j2csz                   2/2     Running   1          21d
longhorn-csi-plugin-tj5jn                   2/2     Running   2          21d
longhorn-csi-plugin-x9hwg                   2/2     Running   1          21d
longhorn-driver-deployer-7488ccf89b-rkf5k   1/1     Running   0          21d
longhorn-manager-46x72                      1/1     Running   1          21d
longhorn-manager-spt8v                      1/1     Running   2          21d
longhorn-manager-wb76f                      1/1     Running   6          21d
longhorn-ui-5b58f6d79d-srcrk                1/1     Running   0          21d

Based on that hint I decided to follow this procedure: https://github.com/longhorn/longhorn/issues/425#issuecomment-468893915 which fixed the issue for me.


propose moving code coverage to build command

Introduction
Ideally I would like to run
swift build --enable-code-coverage

Currently generating code coverage is tied to running tests
swift test --enable-code-coverage

Swift-evolution thread: Discussion thread topic for that
proposal
Motivation
I would like to move enabling code coverage to the build phase as there are times where I would like to skip rebuilding of the source.
swift test --skip-build

swift test --skip-build --enable-code-coverage // This fails

This would help with my continuous integration process.

@thecb4 I don’t know what others would have to say, but at my point of view, your proposal is more related to SwiftPM implementation than the Swift Evolution process itself.
my2cents

It is. The team let me know that I should go ahead and do a pull request directly on SwiftPM after I posted this.
Cheers,
CB

On May 28, 2019, at 17:37, Thiago Holanda<EMAIL_ADDRESS>wrote:
@thecb4 I don’t know what others would have to say, but at my point of view, your proposal is more related to SwiftPM implementation than the Swift Evolution process itself.
my2cents
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@thecb4 awesome! Sometimes It’s a pleasure to be wrong. Thanks for the information! 😉

Hey @thecb4, this doesn't need to go through swift-evolution. Feel free to file a bug report on bugs.swift.org or open a PR if you'd like to contribute!


Fix info metrics

Fixes the info metric which was showing stale values. The calculation of this metric is slightly more complex than I originally thought. Now it should work, I have also added tests that validate the metrics generation works as expected.
/kind bug
/priority important-longterm
/assign

/ok-to-test

/lgtm

/approve


Cannot launch 'Azure CosmosDb Emulator' on 'Hosted VS2017' agent

I want to add launching 'Azure CosmosDb Emulator' as a part of CI pipeline using following command line command:
"C:\Program Files\Azure Cosmos DB Emulator\CosmosDB.Emulator.exe" /noui /noexplorer
It runs infinite amount of time without logs and then fails due to timeout.

@ykonovalets Thank you for your feedback. The issues in this repo are for content feedback, can you let me know the URL of the article that goes with this feedback so I can pass it along to the correct author? If this is a product issue (something not working properly, or a feature request), please file an issue here: https://developercommunity.visualstudio.com/spaces/21/index.html
Thank you.


Multi app run does not understand dependencies and ordering - leads to timing issues

Expected Behavior
Ideally multi app run files dapr.yaml understand DependsOn or priorities of dependencies so we can avoid issues like < https://github.com/dapr/quickstarts/issues/1048 >.
@yaron2 suggest we assign to CLI maintainer for 1.15.

I cannot debug my binding because it starts after the program that uses it and there is no way to wait for the binding to start.

Not stale


[Bug]: getEvents() lost record data

What happened?
I'm embbeding the calendar widget within a custom filament page. Everything works ok, until a change is performed which dispatches an update, hence a re-call to getEvents() and a failure about "record is null"
When I add or delete I lost my $this->record previously passed as an argument and working in the initial request
How to reproduce the bug
class ServiceAvailabilitiesWidget extends CalendarWidget
{
...
  public function getEvents(array $fetchInfo = []): array
  {
          return ServiceAvailability::query()
              ->where('service_id', $this->getRecord()->getKey()) <-- here to filter
              ->get()
              ->map(fn (ServiceAvailability $availability) => $availability->toEvent())
              ->toArray();
  }
...
}

Crea a filament Page
<?php

namespace App\Filament\Resources\ServiceResource\Pages;

use App\Filament\Resources\ServiceResource;
use Filament\Resources\Pages\Concerns\InteractsWithRecord;
use Filament\Resources\Pages\Page;

class ServiceAvailabilities extends Page
{
    use InteractsWithRecord;

    protected static string $resource = ServiceResource::class;

    protected static string $view = 'filament.resources.service-resource.pages.service-availabilities';

    public function mount(int | string $record): void
    {
        $this->record = $this->resolveRecord($record);
    }
}

The blade view:
<x-filament-panels::page>
  @livewire(App\Filament\Widgets\ServiceAvailabilitiesWidget::class, ['record' => $record])
</x-filament-panels::page>

Package Version
1.4.0
PHP Version
8.3.x
Laravel Version
11.9.x
Which operating systems does with happen with?
macOS
Notes
No response

The "record" inside the calendar widget has nothing to do with your filament page record.
Inside the calendar widget, record is most of the times "null" and is only set when an action is mounted or when the context menu is opened, for example.

Should be now fixed in v1.4.1.
getRecord() and getModel() is now deprecated for backwards compatibility and you should use getEventRecord() and getEventModel() respectively.
The property is now called eventRecord.
So whenever you work with the record of the event from within the calendar widget, you should use getEventRecord().
If you use a resource widget and need to access the current resource record, you need to add a public $record property to your widget and access that, as described in the filament documentation here.
If you still encounter any issues, please provide a reproduction repository with what you're trying to achieve, so I can test and debug it.

It works like a charm! thank you!


Network loaded via association of BrainSimII to XML files fails to read descriptions XML

Describe the bug
If a system is set up to open XML files as BrainSimII network files, double-clicking an XML file ends in an exception because Brain Simulator II attempts to open a ModuleDescriptions.xml file which does not exist in relation to the current directory which is C:\Windows\System32.
Application: Brain Simulator
Module/Network: N/A
To Reproduce
Steps to reproduce the behavior:

Right click a BrainSimII network file.
Select Open with, and set it to open with Brain Simulator II (always use this).
Now select a network file in C:\Program Files\FutureAI\Brain Simulator II\Networks.
Double-click it to start Brain Simulator II.
Notice the exception being caught, since the path constructed is wrong.

By trying with different files, it appears the path for the ModuleDescriptions.xml file is created for the relative path '.\Networks\ModuleDescriptions.xml' while it should be using the absolute installation path of the Brain Simulator II program, with \Networks\ModuleDescriptions.xml added to it.
Expected behavior
ModuleDescriptions.xml should always be loaded from a fixed position, not relative to current directory.
Screenshots

Desktop (please complete the following information):

OS: Windows 10 Pro  20H2
Version 20210725 master

Add any other context about the problem here.

The fix to load the file correctly from the application's Networks folder has been added, so it will no longer raise an Exception.