Context is preserved between two runPromise calls

Running the command in sequence preserves the context. I would expect that each call would create a clean context, like is the case with run
Is that normal behavior?
    await namespace.runPromise(async () => {
        set("foo", "bar");
        const foo = get("foo");
        console.log("VAELU", foo);
      })

    await namespace.runPromise(async () => {
      const foo = get("foo");
      console.log("Value", foo); // Here is prints "bar" instead of undefined
    });

I'm seeing this as well.  I store a transaction client via set("client", client).  Client is released at end of transaction but in a subsequent runPromise call this client remains assigned to that property key, and throws an exception because an attempt is made to release the same client twice.

I think I'm seeing this in run calls as well, leading to weird issues between http requests. Once I started to clear any references (setting them to null), things were back to normal. This started appearing when switching from Node 10 to version 12.

I'm dealing with something like this. I have a system that receives HTTP requests and also subscribes to Pubsub topics, it creates a new context for each HTTP request (with ns.run()) and every Pubsub message (with ns.runAndReturn()).
Each transaction is supposed to generate a new transactionId (UUID), unless it is sent over by headers or in the message metadata, in that case a new context is created with but with the received transactionId, so we can trace the related transactions over our microservices.
The problem is we're seeing the same transactionId being repeated a lot across thousands of different unrelated requests, and we can only assume it's an issue with cls-hooked (and not the uuid generation lib).
I don't know if it's related to this issue, because I'm not using the ns.runPromise(), but it might be... I'm not yet able to consistently reproduce it, and as soon as I can, I'll post here or create a separate issue.

Just come across this issue, too. Changed to using runAndReturn instead, and that seems to have fixed it for me. Should just be a literal swap out since it will be returning the promise of your async methods

Just come across this issue, too. Changed to using runAndReturn instead, and that seems to have fixed it for me. Should just be a literal swap out since it will be returning the promise of your async methods

Have a look at the last comments from me (DavidShard) to the first answer https://stackoverflow.com/questions/66665783/memory-leak-in-cls-hooked-or-wrong-use
This is a memory leak bug in cls-hooked that can be fixed by:
72c72
<   let context = Object.create(this.active ? this.active : Object.prototype);
---
>   let context = {...this.active };
316c316
<         namespace._contexts.set(asyncId, namespace.active);
---
>         namespace._contexts[asyncId] = namespace.active;
326c326
<         const triggerIdContext = namespace._contexts.get(triggerId);
---
>         const triggerIdContext = namespace._contexts[triggerId];
328c328
<           namespace._contexts.set(asyncId, triggerIdContext);
---
>           namespace._contexts[asyncId] = triggerIdContext;
364c364
<       context = namespace._contexts.get(asyncId) || namespace._contexts.get(currentUid);
---
>       context = namespace._contexts[asyncId] || namespace._contexts[currentUid];
397c397
<       context = namespace._contexts.get(asyncId) || namespace._contexts.get(currentUid);
---
>       context = namespace._contexts[asyncId] || namespace._contexts[currentUid];
424c424
<       namespace._contexts.delete(asyncId);
---
>       delete namespace._contexts[asyncId];

The effect is that 900k await ns.runPromise() only leave 5000 contexts in memory.
Before node --max-old-space-size=100 was able to only able to execute 100k of them before the GC killed node.

I think the problem is that Map() creates a cyclic dependency between the map and the context.
So releasing the context in this.exit() will never trigger the async_hook destroy to remove the context from the map. Thats what I think.
Such a context object looks like:
12919 | 244 | 560 % | 1 607 39225 % |
-- | -- | -- | -- | --
proto::Object@112915 | 245 | 560 % | 1 607 05625 % |
map::system / Map@111615 | 245 | 720 % | 2800 % |
_ns_name::"a6a29a6f-6747-4b5f-b99f-07ee96e32f88"@37301🗖 | 5 | 560 % | 560 % |
properties::system@259
The cyclic dependency is the map property that points to this._context in the the context.

Have a look at the last comments from me (DavidShard) to the first answer https://stackoverflow.com/questions/66665783/memory-leak-in-cls-hooked-or-wrong-use
This is a memory leak bug in cls-hooked that can be fixed by:
30c30
<   this._contexts = new Map();
---
>   this._contexts = {};
72c72
<   let context = Object.create(this.active ? this.active : Object.prototype);
---
>   let context = {...this.active };
316c316
<         namespace._contexts.set(asyncId, namespace.active);
---
>         namespace._contexts[asyncId] = namespace.active;
326c326
<         const triggerIdContext = namespace._contexts.get(triggerId);
---
>         const triggerIdContext = namespace._contexts[triggerId];
328c328
<           namespace._contexts.set(asyncId, triggerIdContext);
---
>           namespace._contexts[asyncId] = triggerIdContext;
364c364
<       context = namespace._contexts.get(asyncId) || namespace._contexts.get(currentUid);
---
>       context = namespace._contexts[asyncId] || namespace._contexts[currentUid];
397c397
<       context = namespace._contexts.get(asyncId) || namespace._contexts.get(currentUid);
---
>       context = namespace._contexts[asyncId] || namespace._contexts[currentUid];
424c424
<       namespace._contexts.delete(asyncId);
---
>       delete namespace._contexts[asyncId];

The effect is that 900k await ns.runPromise() only leave 5000 contexts in memory.
Before node --max-old-space-size=100 was only able to execute 100k of them before the GC killed node.
Only: let context = {...this.active }; does not solve the memory leak alone.
Only together with replacing the Map by a normal object the leak is gone.
The test code (ns_simple.js):

const httpContext = require('express-http-context');

async function t2(l) {
  if (l > 1) {
  }
}

async function t1() {
  let start = Date.now();
  for (let i = 0; i < 90000000; i++) {
    await httpContext.ns.runPromise(t2);
    if (i % 1000 === 0) {
      const now = Date.now();
      console.log(` ${i + 1}, dur=${now - start}ms`);
      start = now;
    }
  }
}

t1()

With node 14.15.5
time node --max-old-space-size=10 ns_simple.js
$ time node --max-old-space-size=10 ns_simple.js
 1, dur=1ms
 1001, dur=30ms
 2001, dur=38ms
 3001, dur=55ms
 4001, dur=75ms
 5001, dur=115ms
 6001, dur=149ms
 7001, dur=186ms
 8001, dur=236ms
 9001, dur=294ms
 10001, dur=339ms
 11001, dur=391ms
 12001, dur=435ms
 13001, dur=480ms
 14001, dur=531ms
 15001, dur=579ms
 16001, dur=627ms
 17001, dur=666ms
 18001, dur=727ms
 19001, dur=794ms

<--- Last few GCs --->

[1664:00000229A831E200]     6834 ms: Mark-sweep (reduce) 8.6 (10.8) -> 8.6 (11.8) MB, 3.5 / 0.0 ms  (average mu = 0.813, current mu = 0.005) last resort GC in old space requested
[1664:00000229A831E200]     6838 ms: Mark-sweep (reduce) 8.6 (10.8) -> 8.6 (11.8) MB, 4.3 / 0.0 ms  (average mu = 0.678, current mu = 0.002) last resort GC in old space requested

<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 00007FF620DA058F napi_wrap+109311
 2: 00007FF620D452B6 v8::internal::OrderedHashTable<v8::internal::OrderedHashSet,1>::NumberOfElementsOffset+33302
 3: 00007FF620D46086 node::OnFatalError+294
 4: 00007FF62161153E v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF6215F63BD v8::SharedArrayBuffer::Externalize+781
 6: 00007FF6214A084C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1516
 7: 00007FF62149BC61 v8::internal::Heap::AllocateExternalBackingStore+1569
 8: 00007FF6214B5E06 v8::internal::Factory::AllocateRaw+166
 9: 00007FF6214C9824 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller+84
10: 00007FF6214C9B23 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithMap+35
11: 00007FF6212D0C6C v8::internal::OrderedHashTable<v8::internal::OrderedHashMap,2>::Allocate+124
12: 00007FF6212D346B v8::internal::OrderedHashTable<v8::internal::OrderedHashMap,2>::Rehash+59
13: 00007FF6212D224A v8::internal::OrderedHashTable<v8::internal::OrderedHashMap,2>::EnsureGrowable+90
14: 00007FF621209737 v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+122119
15: 00007FF621699EED v8::internal::SetupIsolateDelegate::SetupHeap+463949
16: 00007FF6216753C8 v8::internal::SetupIsolateDelegate::SetupHeap+313640
17: 0000012C6E447C5F

real    0m6.984s
user    0m0.000s
sys     0m0.000s

With the fix:
$ time node --max-old-space-size=10 ns_simple.js
 1, dur=1ms
 1001, dur=17ms
 2001, dur=10ms
 3001, dur=10ms
 4001, dur=6ms
 5001, dur=11ms
 6001, dur=7ms
 7001, dur=5ms
 8001, dur=6ms
 9001, dur=6ms
 10001, dur=12ms
 11001, dur=7ms
 12001, dur=6ms
 13001, dur=6ms
 14001, dur=5ms
...
...
...
 886001, dur=7ms
 887001, dur=12ms
 888001, dur=7ms
 889001, dur=9ms
 890001, dur=8ms
 891001, dur=7ms
 892001, dur=11ms
 893001, dur=10ms
 894001, dur=7ms
 895001, dur=9ms
 896001, dur=13ms
 897001, dur=6ms
 898001, dur=8ms
 899001, dur=7ms

real    0m7.788s
user    0m0.000s
sys     0m0.016s

ns.runPromise() will cause _contexts grow by 4 for every run, so the issue you're facing is actually the rate of growth of _contexts is so high than destroy hook didn't get to run, hence the Memory Issue.
Let's simplify this, try to rerun ns_simple.js with ns.run then, add the following debug to the destroy hook of context.js
destroy(asyncId) {
      currentUid = async_hooks.executionAsyncId();
      if (DEBUG_CLS_HOOKED) {
        const triggerId = async_hooks.triggerAsyncId();
        const indentStr = ' '.repeat(namespace._indent < 0 ? 0 : namespace._indent);
        debug2(`${indentStr}DESTROY (${name}) currentUid:${currentUid} asyncId:${asyncId} triggerId:${triggerId} active:${util.inspect(namespace.active, {showHidden:true, depth:2, colors:true})} context:${util.inspect(namespace._contexts.get(currentUid))}`);
      }
      debug1(`deleteHookRan here`) // Add this line, so you can see when the destroy hook is called
      namespace._contexts.delete(asyncId);
    }
  });

// As you can't console log inside async hook
function debug1(...args) {
    process._rawDebug(`${util.format(...args)}`);
}

There is a big difference when you do await ns.run(t2) and just ns.run(t2) in your ns_simple.js
await version will not fail, while the one without await will fail.
This is because await will turn converting anything that isn't a Promise into a resolved Promise.

@SimonX200
The following might help you to visualize the difference
for (let i = 0; i < 90000000; i++) {
    const context = await session.run(t2);
    console.log(context);
    // { _ns_name: 'benchmark', id: 5 }
    // { _ns_name: 'benchmark', id: 11 }
    // { _ns_name: 'benchmark', id: 14 }

    // const context = session.run(t2);
    // console.log(context);
    // { _ns_name: 'benchmark', id: 1 }
    // { _ns_name: 'benchmark', id: 1 }
    // { _ns_name: 'benchmark', id: 1 }

    if (i % 1000 === 0) {
      const now = Date.now();
      console.log(` ${i + 1}, dur=${now - start}ms`);
      start = now;
    }
  }

@Darkripper214
Actually when using async functions there will be always a await somewhere. So, for me the change fixes my/our problem. I haven't run the regression tests but I think they will also work.
That the destroy never happens when using async but never an await is fine for me.
I find it interesting that Map() creates a back-link to itself to all added objects.
For me that is just another reason to use the most basic directly support features of an development eco system where possible.
I find it also interesting that Object.create(previous_context) creates such a deep object. And that the deeper the object becomes, the longer Object.create(...) takes.
I wonder why it was used. Probably because of legacy node versions that did not support {...previous_context)?

@Darkripper214
Actually when using async functions there will be always a await somewhere. So, for me the change fixes my/our problem. I haven't run the regression tests but I think they will also work.
That the destroy never happens when using async but never an await is fine for me.
I find it interesting that Map() creates a back-link to itself to all added objects.
For me that is just another reason to use the most basic directly support features of an development eco system where possible.
I find it also interesting that Object.create(previous_context) creates such a deep object. And that the deeper the object becomes, the longer Object.create(...) takes.
I wonder why it was used. Probably because of legacy node versions that did not support {...previous_context)?
Note:

There is a big difference when you do await ns.run(t2) and just ns.run(t2) in your ns_simple.js

Change your loop:
const context = session.run(t2)
await 1;
and it works again.

Yeap,  there will be 2 promise generated when there is async func (Can check it via init hook).
The point is that it is never a memory leak issue, it was that the server was flooded before it can even destroy the contexts

@Darkripper214
I don't agree with "that it is never a memory leak issue", because:
Why is it fixed by just changing Map to to plain Object and by not using Object.create()?
This does not change anything else except that extensive linking of context's.

await namespace.runPromise(async () => {
    set("foo", "bar");
    const foo = get("foo");
    console.log("VAELU", foo);
  })

await namespace.runPromise(async () => {
  const foo = get("foo");
  console.log("Value", foo); // Here is prints "bar" instead of undefined
});

My changes did not fix that yet.
I see the problem in exit(). this.active is only changed if it is equal to the context to exit.
Since this.active is a global it is probably changed by each async call.

@Darkripper214
I don't agree with "that it is never a memory leak issue", because:
Why is it fixed by just changing Map to plain Object and by not using Object.create()?
This does not change anything else except the extensive linking of context's (from my point of view: unnecessary. The _contexts is the retainer or the context is on some arguments stack and retained by that. No one access the previous context through the current context).

It is definitely not a memory leak issue, as context is being cleared if ns.run() is not overwhelming the process by keeping the call stack filled.
You might want to call it as bug for your use case, which I think doesn't really make sense, since it is blocking the event loop.

await namespace.runPromise(async () => {
    set("foo", "bar");
    const foo = get("foo");
    console.log("VAELU", foo);
  })

await namespace.runPromise(async () => {
  const foo = get("foo");
  console.log("Value", foo); // Here is prints "bar" instead of undefined
});

My changes did not fix that yet.
I see the problem in exit(). this.active is only changed if it is equal to the context to exit.
Since this.active is a global it is probably changed by each async call.
Update:
The problem is the management uses asyncId as 'global uniq' while asyncId is not.
It is provided by newAsyncId() and that seems not to be globally unique.
The sequence of asyncId's is equal in the next ns.runPromise
The newAsyncId() seems to return just the async stack depth.
Update2:
I think the use of asyncId as global unique in cls-hooked is a wrong use. In nodejs I see:
// Internal Embedder API //

// Increment the internal id counter and return the value. Important that the
// counter increment first. Since it's done the same way in
// Environment::new_async_uid()
function newAsyncId() {
  return ++async_id_fields[kAsyncIdCounter];
}

This guaranties no uniqueness. It creates a simple sequence of number.
I assume that the asyncId is not supposed to be used as global unique by node.
@Darkripper214
And this means that asyncId will collide and will corrupt httpContext.get() and httpContext.set()
We have seen that. Some deep low-level methods use httpContext.get() and they got something while running outside of any context. It was expected that undefined is returned. That's why we even put all our timers and intervals into a ns.runPromise to be able to set the httpContext values explicitly to nulls.
So multiple ongoing http requests can corrupt other http request httpContext.get()
This is a major issue

I will take a look on the cyclic referencing of map as reported.
But still, the use case for this is to enable the passing of context around when the process is running, why is an auto-increment of asyncID pose an issue?

But still, the use case for this is to enable the passing of context around when the process is running, why is an auto-increment of asyncID pose an issue?

Because it repeats. When debugging the  example code from the issue-starter and break in before() I see duplicate asyncId's.
In the second ns.runPromise() I see the same asyncId's as in the before of the first ns.runPromise()
Either the async_id_fields get reset, or something else is happening. I have not yet found the code in the node repo that could cause that.

@SimonX200
asyncId didnt get repeated, what you see inside _contexts are just a list of past context that is a place for us too lookup. You can check the asyncID by running all the init, before , after hooks and see for yourself. It never repeats, but _contexts have a lot of repeating past context. This is the behavior that you were complaining about for the excessive usage of memory when doing some extreme loop.
init hook inside context.js
if(namespace.active) {
        namespace._contexts.set(asyncId, namespace.active);

This is to save the current context to be retrieved when before hook is called,
before hook inside context.js
currentUid = async_hooks.executionAsyncId(); \\ This will give you current execution context
//HACK to work with promises until they are fixed in node > 8.1.1
      context = namespace._contexts.get(asyncId) || namespace._contexts.get(currentUid);
// Here, we either get our specific context from `asyncId` or just take the parent from `currentUid`

So the erratic behavior that is being reported is actually caused by the way this.enter(context) and this.exit(context) is run in the before and after hook.
If you look at the this.active inside the closure of the namespace, it is supposed to be null after every ns.run() or ns.runPromise().
When it is not cleared, then the context will be passed as a prototype to the new context being created
let context = Object.create(this.active ? this.active : Object.prototype);

The core issue with this bug is actually with the feature of ns.run to pass the parent context down to the child if the key doesn't; exists in the child context.
This can be solved by updating the createContext(), But this will be a breaking change for those who rely on this behaviour.
// let context = Object.create(this.active ? this.active : Object.prototype);
let context = {} \\ This should work

@Jeff-Lewis May I know your opinion on this?

@Darkripper214
My assumption that different running ns.run could share the same context was wrong.
To test my assumption I extended the issue-starter's code to multiple ongoing ns.run. With that the context is never shared. Not even at first.
const httpContext = require('express-http-context');
const FIELD = 'foo';
function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}
function checkAndSet(val) {
  const gval = httpContext.get(FIELD);
  if (gval !== val) {
    if (gval) {
      console.error('change detected', gval, ' expected ', val);
    }
    httpContext.set(FIELD, val);
  } else {
    console.info('ok', val);
  }
}
async function t1() {
  const val = 'abc0';
  await sleep(500);
  while (true) {
    checkAndSet(val);
    await sleep(1000);
  }
}
async function t2() {
  const val = 'xyz1';
  while (true) {
    checkAndSet(val);
    await sleep(1000);
  }
}

async function tx() {
  httpContext.ns.run(t1);
  httpContext.ns.run(t2);
}

tx();

$ node test_ns2
ok xyz1
ok abc0
ok xyz1
ok abc0
ok xyz1
ok abc0

Now regarding my problem:
To guarantee that our project core functions get proper values from httpContext.get() when execute outside of http request we use the await httpContext.ns.runPromise(async () => { httpContext.set(...); await actual_function(); })
We have 3 10 seconds interval timer and other minute intervals running. These functions need like 1-2 seconds until their data were returned from database and were processed.

All in all, I think this bug is rather specific, it should only occur when there are multiple ns.run in the same lifecycle of a request.
I am quite sure that this usage pattern is quite common.

Without the changes I posted above the heap grows by 24MBytes per day with only one http request every few minutes.
After 7 hours there are already the mentioned 60k contexts and about 8MBytes.  Not sure where the 60k contexts come from. Every 10s for 7h should result in 3x2520 await ns.runPromise() calls.
Update: Just now I found a wrong configured 10s timer that was running in 10ms.
That 10ms plus the db delay can result in 60k ns.runPromise() calls in 7h.
Since very new createContext gets slower by the number of previous createContext calls the whole applications gets slower.
After 60k createContext each createContext needs 2.2ms (on a 5950x at 4.9GHz, single thread)
This does not only affect the timers but also every ns.run by a http request.
For us the increase of 24MBytes per day for nothing is a major issue because our webapp runs continuously as Azure WebApp with limited memory. We already increase the memory from 1.7G to 3G by doubling the Azure costs.
We have also noticed that our webservice becomes slower and slower the longer it runs.
We investigated in searching for memory leaks in our software and to optimize our code.
The current solution is that the 10 seconds timers are not using any express-http-context and to use just one httpContext.set() with an object that stores the needed data. The references inside that object we reset after every http request and timer before we set the httpContext key to null itself.
Fortunately the 10 seconds timers actually it didn't needed a httpContext. Here we were lucky and our application is already running much smoother and without a memory leak.
The minute timers still have to use httpContext.
Update
Since I just found the wrong 10ms timer I can estimate the current memory loss per day with 3 minute timers (=1440*3) and no http request:
Instead of 24MByte per day now 589kByte.
The performance degeneration of the mentioned 2.2ms (on a 5950x at 4.9GHz (single thread), Azure WebApps are running on some old Xeon, so multiply that by 10) per ns.run is reached after 15 days.
After 30 days each ns.run will need at least 11ms (on a 5950x at 4.9GHz)
 132001, dur=9973ms
 133001, dur=10160ms
 134001, dur=10251ms
 135001, dur=10479ms
 136001, dur=10691ms
 137001, dur=10889ms
 138001, dur=11134ms
 139001, dur=11362ms

@SimonX200
Can you show how your team is doing the following?
To guarantee that our project core functions get proper values from httpContext.get() when execute outside of http request we use the await httpContext.ns.runPromise(async () => { httpContext.set(...); await actual_function(); })
I still don't get it how ns.run will cause degradation. Do note that it is developer responsibility to ensure that there are no object referencing the context after it is not being used (So GC can clear everything). The other way is to come up with a way to clear all context within ns.run.
I'm thinking that the _contexts and _set could use an object with keys, then directly find the right context using the asyncID executionID and ``triggerID. That will solve the overgrowth of _contexts` in current implementation.

@Darkripper214
The following most simple code shows the degradation perfectly.
const httpContext = require('express-http-context');

const END = 120000;

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function t1(l) {
  if (l > 1) {
  }
}

async function tx() {
  let prev_avr_delta = 0;
  let avr_delta_sum = 0;
  let avr_cnt = 0;
  for (let loop = 0; loop < END; loop++) {
    const start = Date.now();
    await httpContext.ns.runPromise(t1);
    const delta = Date.now() - start;
    avr_delta_sum += delta;
    avr_cnt++;

    if (loop % 1000 === 0) {
      const avr_delta = avr_delta_sum / avr_cnt;
      console.log(`loop ${loop}, avr per runPromise: ${avr_delta.toFixed(3)} ms`);
      prev_avr_delta = avr_delta;
      avr_cnt = 0;
      avr_delta_sum = 0;
    }

    if (loop % 100 == 0) {
      await sleep(10);
    }
  }
}

tx();

This is the most basic use of ns.runPromise() with the most basic function (that shows the problem) being called.
You can play around with global.gc() or longer/more sleeps without any change.
In the end a single ns.runPromise() needs 7.8ms for doing nothing on a 5950x.

@Darkripper214
Some notes to the cls-hooked code:
The _set is actually a _stack.
The use of async_hook destroy is wrong. destroy() is called before after(). See emitHook (or so) by stepping into the async hook stuff. destroy is called() in a finally before after(). The effect is that exit() is never called when destroy() is called.

@SimonX200
I still cant reproduce the result on Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz   2.60 GHz. Performance-wise, it shouldn't vary that much.
I even remove the sleep(10) and run with -max-old-space-size=25.
This is the result I got.
loop 16294000, avr per runPromise: 0.008 ms
loop 16295000, avr per runPromise: 0.008 ms
loop 16296000, avr per runPromise: 0.008 ms
loop 16297000, avr per runPromise: 0.008 ms
loop 16298000, avr per runPromise: 0.008 ms
loop 16299000, avr per runPromise: 0.008 ms
loop 16300000, avr per runPromise: 0.039 ms \\ This pop up every once in a while, GC stuff running?
loop 16301000, avr per runPromise: 0.007 ms
loop 16302000, avr per runPromise: 0.008 ms
loop 16303000, avr per runPromise: 0.006 ms
loop 16304000, avr per runPromise: 0.008 ms
loop 16305000, avr per runPromise: 0.008 ms
loop 16306000, avr per runPromise: 0.007 ms
loop 16307000, avr per runPromise: 0.007 ms
loop 16308000, avr per runPromise: 0.009 ms
loop 16309000, avr per runPromise: 0.008 ms
loop 16310000, avr per runPromise: 0.007 ms

Yeah, I know that _set in current implementation is a stack. The issue with the implementation is relying on the sequence of async_hook to get to its previous context, which I don't really know when will this behavior be useful.
The implementation is sort of messy especially when there is any complex async operation (Try opening a socket or do a fetch with async_hook and you will see). The other way to fix this might be to limit the enter(context) and exit(context) to only PROMISE type. But this would involve having another data structure to keep track of asyncID to type of Promise

@Darkripper214
Hmm,
{
  "engines": {
    "node": ">= 12.14.1",
    "npm": ">= 6.13.4"
  },
  "dependencies": {
    "express-http-context": "^1.2.4"
  }
}

npm list
`--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | +--<EMAIL_ADDRESS>  | | | `--<EMAIL_ADDRESS>deduped
  | | `--<EMAIL_ADDRESS>deduped
  | +--<EMAIL_ADDRESS>  | | +--<EMAIL_ADDRESS>deduped
  | | +--<EMAIL_ADDRESS>deduped
  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  |   +--<EMAIL_ADDRESS>  |   `--<EMAIL_ADDRESS>deduped
  `--<EMAIL_ADDRESS>    +--<EMAIL_ADDRESS>    | `--<EMAIL_ADDRESS>    +--<EMAIL_ADDRESS>    | `--<EMAIL_ADDRESS>    `--<EMAIL_ADDRESS>

node -v
v14.15.5
I see the same behavior also with node v14.16.0
I also did it for the Xeon test on a complete new environment with fresh installed node.

The only thing that must be changed for fix performance and memory leak is:
diff --git a/context.js b/context.js
index 1fad2cb..9ad4472 100644
--- a/context.js
+++ b/context.js
@@ -69,7 +69,7 @@ Namespace.prototype.get = function get(key) {

 Namespace.prototype.createContext = function createContext() {
   // Prototype inherit existing context if created a new child context within existing context.
-  let context = Object.create(this.active ? this.active : Object.prototype);
+  let context = { ...this.active };
   context._ns_name = this.name;
   context.id = currentUid;

@@ -473,5 +473,3 @@ function debug2(...args) {
     return fn.constructor.name;
   }
 }*/
-
-

I added a memory test and a performance test to the mocha tests.
However I cannot push the branch to open a pull request.

@SimonX200
I'm using node v15.0.1 for all the test. Not sure why there is such huge divergence in the result.
I assure you that by replacing _contexts from map to object did little to improve on the memory issue. I've done some test and _contexts is still having the same behavior of appending the same context (with different asyncId but same executionAsyncId).

As far as I'm concern, there are two issues with the current implementation

Excessive Memory usage from having the same context with different asyncID appended into _contexts,It is not a severe bug as long nothing is blocking destroy hook from running. But of course, we should improve if it is possible.

Incorrect behaviour of runPromise, which is explained in my comment above. This is a severe bug and should be fix ASAP.
https://github.com/Jeff-Lewis/cls-hooked/issues/63#issuecomment-803076914

@Darkripper214
I prefer minimal changes to prevent side effects. Also the performance test runs consistently 100ms (of 16850ms) or 0.6% faster with Map than with Object. Map however needs a few percent more memory.
I have cloned the repo and pushed my change into that one. Have a look at the tests memory-leak.test.js and performance-leak.test.js. The memory-leak test requires a max-old-space-size of at most 25M which is set in package.json for npm test.
https://github.com/SimonX200/cls-hooked
Also I have tried node v15.0.1 and I still see the performance problem when running the performance tests against the original code. I use nvm to install and switch node versions. But I have tried it also with plain node 14 lts installations and a development free laptop and on a linux-vm with a fresh node 14.16.
When I enable the console.log in the performance-leak.test.js and the context.js from the master then I see:
$ node -v
v15.0.1
$ ./node_modules/mocha/bin/mocha test/performance-leak.test.js

  cls performance leak
1 0 0.02 1.02
2 0 0.02 1.02
3 0 0.03 1.02
4 0 0.03 1.02
5 0 0.02 1.02
6 0 0.03 1.02
7 0 0.03 1.02
8 0 0.03 1.02
9 0 0.04 1.02
10 0 0.05 1.02
11 0 0.04 1.02
12 0 0.05 1.02
13 0 0.04 1.02
14 0 0.05 1.02
15 0 0.07 1.02
16 0 0.05 1.02
17 0 0.05 1.02
18 0 0.06 1.02
19 0 0.07 1.02
20 0 0.07 1.02

..
..
..

346 11 1.24 1.02
347 11 1.25 1.02
348 11 1.25 1.02
349 12 1.27 1.02
350 12 1.27 1.02
351 13 1.28 1.02
352 13 1.27 1.02
353 13 1.28 1.02
354 14 1.29 1.02
355 14 1.29 1.02
    1) Execute ns.runPromise

  0 passing (24s)
  1 failing

  1) cls performance leak
       Execute ns.runPromise:

      AssertionError: expected 15 to be below 15
      + expected - actual

      at Context.<anonymous> (test\performance-leak.test.js:47:34)

The same I see in the linux-vm.
BTW: Was just running the performance test in a wsl2 debian linux on windows and there the performance test with my code completes within 2500ms (for 100000 ns.runPromise). In windows on the same PC it needs 16800ms. The Object is still consistently 100ms slower than the Map (2.6s against 2.5s). Looks like a fixed time offset.

@SimonX200 You're right on the traversal of __proto__. This issue will be easily solved by
Replacing
let context = Object.create(this.active ? this.active : Object.prototype);
with
let context = { ...this.active }
This would make the context more flat and would solve the case where deep traversal is hurting performance.
But would this solve the memory issue you're facing in your project?

@Darkripper214

But would this solve the memory issue you're facing in your project?

Yes, it does.
The memory-leak.test.js (executed with --max-old-space-size=20) shows that too.
Because ns.active is random when not being inside an async function (which is protected by async_hook) also the sync ns.run() in the express-http-context middleware could increase the depths of the contexts.
BTW:
The soft linking of the previous context to the current one means that changes of the outer context after the ns.run() will be visible in the inner context. Is that a feature?

Also ns.runPromise always leaves an ns.active != null
      for (let j = 0; j < INNER_LOOPS; j++) {
        await ns.runPromise(t2);
        while (ns.active) {
          await sleep(10);
        }

The while loop never ends.
This happens already after the first finished await ns.runPromise().

For our project we have decided to switch to plain AsyncLocalStorage.
It provides everything we need and should be stable.
I will adapt my performance and memory leak test to it to see if it is really so.
Once I verified that is it stable I will suggest to express-http-context to switch to AsyncLocalStorage as this is what currently most webserver use.

@SimonX200
You can take a look at this
https://github.com/Darkripper214/ALS-Context
My aim is to implement context library with consistent implementation with AsyncLocalStorage. You can take a look at the test file.
I'm planning to add a different flavor of cls-hooked that is more in-line with AsyncLocalStorage, with all the bindemitter stuff for AsyncLocalStorage to work with EE.

@Darkripper214
While investigating more into AsyncLocalStorage I came across this:
https://github.com/nodejs/node/issues/34493
We too have many async that are really waiting.
I found a simple and elegant way to keep a local storage using the V8 call stack-trace by constructing a function inside run()  with the context id being coded into its name. No async_hooks and so only the performance of set()/get() is impacted and that will not impact the project performance.
Very few code lines and works out-of-the-box.
The only theoretical problem is when there are dangling promises still running after the outer run has finished().
They will lose the access to the context once the outmost run() has finished as it deletes the context from the store (Object).

any update on this issue, or it this repo still maintained?

Seems to be not maintained anymore.
See the open pull request that were neither rejected or accepted.
We switched to native AsyncLocalStorage.
Recently I was considering to open  the issue on express-http-context to notify the community about the memory leak of web servers that are not restarted periodically and the wrong context get's of generic project functions outside of http-requests.
Both have the same cause.

I'm running into this issue too with nested runPromise calls - it seems like it's not exiting the context as expected. The "workaround" might be to just use separate namespaces.

Just come across this issue, too. Changed to using runAndReturn instead, and that seems to have fixed it for me. Should just be a literal swap out since it will be returning the promise of your async methods

It works, thank you a lot!


Updating npm to 4.2.10?

Hi, just wondering if you have a timeframe for releasing 4.2.10 to npm?
I'm wondering if I should include MediaElement directly in my project or wait for the update
Thanks!

Hi Ant,
npm has just been updated to 4.2.10


Consider support multi-containers pod error code handling

Currently, the LifecyclePolicy.ExitCode only takes the first container exit code of the pod.
So if users have multi-containers pod,  it is impossible for them to specify the error handling behavior for each container in a pod.
I'd suggest to update the LifecyclePolicy API. Since ExitCode  is just added, I think it is of little risk to do it now.

The initial thought

type LifecyclePolicy struct {
	ExitCode []ExitCode
}

type ExitCode struct {
      containerName string
      code *int32
}

/kind feature
/sig apps

Do we care about any case of the exitCode or we just care about if there are any unsuccessful exitCode among the containers?

Honestly,  in normal case i think it is not necessary.  This is a advanced feature,  maybe useful for those jobs that have some dependencies, for example a training job may return code x when the model data is unavailable, and return y when the data is of invalid format, return z when a temporary network connection err, etc.


Services matched with stories + resources updated

Please add a description so we know what the PR is supposed to cover


Backtrace from API query; post 81600 has no username

I have a code path from Halflife which crashes every time.
The traceback is a humongous pile of HTML which I am attaching here.
The request is
/api/posts/91435;91109;84856;83871;83119;83038;81600;81461;80727;79419

The beef of the error message seems to be in
Showing /var/railsapps/metasmoke/releases/20171031015321/app/views/posts/_post.json.jbuilder where line #7 raised:
    undefined method `username' for nil:NilClass

I managed to pare it down to a simpler test case which triggers on post 81600.
#!/usr/bin/env python

import json
import logging
import sys

import halflife

#logging.basicConfig(level=logging.INFO, format='%(module)s:%(message)s')
logging.basicConfig(level=logging.WARN, format='%(module)s:%(message)s')
with open('halflife.conf') as conffile:
    conf = json.loads(conffile.read())
h = halflife.Halflife(conf['metasmoke-key'])
for idx in [91435, 91109, 84856, 83871, 83119, 83038, 81600, 81461, 80727, 79419]:
    try:
        print('# trying {0}'.format(idx))
        post = {'id': str(idx)}
        h.get_post_metainformation(post)
    except KeyboardInterrupt:
        break

I was speculating that the API filter expression in Halflife was causing this, but I get the traceback even without the filter.

Seems like MS is complaining about nil.username' not working (&#39 is ').
Line 7 of _post.json.jbuilder is:
names: post.flag_logs.select { |f| f.success && f.is_auto }.map { |f| f.user.username },

So it looks like f.user is nil. I took a look at the flag logs page for this report, and sure enough, the first flag log doesn’t have a username in it.

bug buggity bug. Dunno why that doesn't have a user attached.

Another instance with the same symptom.
halflife:2017-11-01 05:49:18,598:Query posts/91541;89083;62604;62600;62596;62587;62571;62559;62543;62501 did not return valid JSON: '\n\n\n \n \n \n\n \n\n\n\n
\n
\n NoMethodError in\n API#posts\n
\n
\n\n
\n

\n Showing /var/railsapps/metasmoke/releases/20171031015321/app/views/posts/_post.json.jbuilder where line #7 raised:\n
\n

undefined method `username' for nil:NilClass

Using the repro script above, I isolated the offending sample: 62559
I don't really care about the user names so I suppose I could perhaps tweak the API query filter to not request this information as a workaround.

E.g. /flagging/users/2/logs returns a backtrace, too; I guess there are user IDs which used to exist but which are now deleted?

There certainly are some of those. Depending on what traceback you're getting, it may just be a 404.


0.3.2

Delimiter support in HipChat

/cc #82

Released: https://www.npmjs.com/package/hubot-stackstorm


Full version also on CDN

Thanks for this great work and sharing the minified versions on CDN (https://cdnjs.com/libraries/gridstack.js).
Request you to kindly put full (non-minified) version also along with the min versions on the CDN, as it helps in debugging and switching to production easily with just a typo.

Files will appear on CDN after release of 0.2.3


Add support to email notification

Based on domains detected possibility to add one or n email addresses to get a notification

This tool aims to "do one thing and do it well". With that said, I can recommend other projects that implement core functionality of dnstwist and on top of that add email notification feature: DomainAware and gfyp.


Spot extraction can break when drift-corrected ROIs table contains floating-point bounds

When the table of regions of interest (ROIs) contains bounding coordinates that are decimals / floating-point values, the spot extraction step (extract_spots.py, after spot detection) can fail because the floating-point values are used as indices to build slices, which is illegal since those indices must be integers.
Traceback (most recent call last):
  File "/looptrace/bin/cli/extract_spots.py", line 30, in <module>
    S.gen_roi_imgs_inmem()
  File "/opt/conda/lib/python3.10/site-packages/looptrace-0.2-py3.10.egg/looptrace/SpotPicker.py", line 372, in gen_roi_imgs_inmem
  File "/opt/conda/lib/python3.10/site-packages/looptrace-0.2-py3.10.egg/looptrace/SpotPicker.py", line 337, in extract_single_roi_img_inmem
TypeError: slice indices must be integers or None or have an __index__ method

Running with 'dog' as the spot detection algorithm for dataset 5853 seems to work, supporting the notion that this is likely solved.


Question about labels

A label file such as \train\scene-0001\000_occ.npy contains a np array with a shape of (39068,2). I have a few questions about this array. 1) Considering that the voxel space is (200,200,16), the 39068 points from the array represent occupied voxels from the 640000 total voxels?
2) I want to train a network that will use labels of shape (200,200,16), is there a place in the code where you translate the (39068,2) labels to the full voxel space?
3) Is there a way to extract only the voxels visible to the FRONT camera, in case I want to predict only the front scene, and not the whole surround scene?
Thank you!

Yes
Please refere to the visualization code, in which the discrtete labels can be transformed into the representation of voxel space.
You need to process the data and project the voxel into the FRONT camera and keep the valid voxel for your setting.

Thank you for your kind response. I do have a few more questions: I see that the flow files contain numpy arrays with shape for eg. (4691,2). 1) The 2 values for each row represent the velocity on both x and y axes? 2) Is there a way to link the flow with the voxel it represents? Is there a way to find out the flow for a specific voxel, from the ground truth provided? Thank you!


Feature Request: Ability to Export JSON File from Wallet

Current Behaviour:
Wallet does point to the location of the JSON file - but the user is unable to export the JSON file itself.
Proposed New Behaviour:
Have the ability to export the JSON file directly from the Molly Wallet - similar to Metamask. This could be located in the Wallet Info page

The JSON file is already the exported version of the private key 🤷
There is no need for additional action.


File New > From Template

I write a lot of more or less repetitive things in VSCode, and it would be nice if I could have a Template for the various JSON documents I work with, that are already stubbed in with the basics. I've not seen a request for something like this, but kind of thinking something akin to how Word might handle it? Perhaps a templates folder with various starter files, so you could just drop like whatever files you want in there, and it just creates a new one based on the file extension, so a sample .ps1 would create a new powershell script, or a sample .json would create a new json document.

@jeffpatton1971 have you tried to snippets? Information here.


display problems

I took a 2.2 "TFT display as recommended and connected it, but a problem emerged.
Display Link (https://www.amazon.de/gp/product/B01E0MGZU2/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1)
In a blog it was shown how it can be connected to the Raspberry Pi and in the linked Github project this was also discussed again. But I have a problem that wasn't described there. After starting the script, the image can only be seen in the upper right part of the display, greatly reduced. Unfortunately, the autostart script does not work properly either. I have to run the script to add it to the autostart after every reboot. In addition, the displayed image flickers as if the frame rate is incorrect.
The Blog(in German)(https://blog.gc2.at/post/spi-tft-lcd-kernel5/)
the GitHubProjekt(english)(https://github.com/juj/fbcp-ili9341)
I very much hope that a solution can be found and that everything works out. Many thanks in advance.

Hi @Johnephen, thank you for the issue report.
It seems like in your current implementation, you're using a different kernel driver (mentioned in the blog) and fbcp command to mirror main output to your display. There are many variables here (and many options) so let me try to provide my way of thinking for your reference:

For the resolution (image only in upper right part) issue, I would check if gpu_mem=256 is added in /boot/config.txt. It's essential for the camera to take the full resolution.
For the not-auto-start script issue, I'd recommend adding a .desktop file under /etx/xdg/autostart folder. You can find more information in this link: https://help.gnome.org/admin/system-admin-guide/stable/autostart-applications.html.en
(And of course you'll need to change the Exec= line to the path of your script)
The flicking and frame rate issue seems to be related to the fbcp command itself, I'd check if correct build flags are used in compiling fbcp

And finally, if it still fails you, please try using the original Raspberry Pi OS overlay driver like I did and see if it works better for you. We had a ticket on that here:
https://github.com/penk/ruha.camera/issues/11
Good luck!

Thank you for this so quick response. I kept looking around for display solutions and a video that actually solved all of my display issues. The autostart also works and the camera script also works. So when I start the Raspberry Pi, I also have a playback of the camera. But I'm still a little dissatisfied with the refresh rate of the playback itself, since that of the display should actually be ok. But I'll look at that again later, whether it's really on the display or on the playback. But thanks again for the answer.
Video I used: https://www.youtube.com/watch?v=uz4sa24C4gk&list=LL&index=4&t=1015s

@Johnephen thanks for the link, I'll look into it too. Feel free to close this issue, if you like.


Add code to scroll suggestion container to show focused item.

When user is selecting items using the keyboard up and down arrows, the container is scrolled if necessary so the newly focused item will be in the visible part. This only makes a difference when the container has max-height and overflow-y properties set.
For this to be useful in an autosuggest widget you also need code there (Pull request #153) to prevent the suggestion scrolled to underneath the mouse cursor from being focused by mistake.

Thanks a lot for this PR!
I put a few comments above, but overall looks great.
Have you had a chance to test it in various browsers, especially IE11+?

@pdc Can we also make sure that we scroll on the first render, if needed.
Otherwise, if we have a focused item, we end up with this:

Any updates?

@pdc Any plans to address the comments above?
@DenisIzmaylov @TigerC10 Can you help with testing this in IE11?

Looks like it working OK.

@pdc Could you update the PR please, and rebase on master to resolve the conflicts?

I have tidied the code up as suggested and rebased against master.
Also, it now checks whether it needs to scroll the suggestions on mount as well as after an update.

Let's merge it?

Just published v3.3.0


⚠ NCAA has degraded performance

In c319490, NCAA (https://www.ncaa.com) experienced degraded performance:

HTTP code: 200
Response time: 2596 ms

Resolved: NCAA performance has improved in d785f52.


Add workflow for maintaining floating tags

If we merge this, we need to cut another release or manually tag v0 to make the readme accurate.


Usages of ulong should be statically rejected?

d2sqlite3 functions accept any integral types, but SQLite's INTEGER is signed integer up to 64 bits. So it can't correctly deal with ulong, unsigned 64 bits integer.

There can be an incorrect behavior with Statement.bind.  It's easy to fix. But statically rejecting ulong might be too vehement.

See a1c18bc4818de43a6c13c83f6440896e75f8d0fa

Thank you!


Implemented new cog for viewing discord message links as embeds.

Created a new cog and command (.link) for displaying messages linked via discord to the user for ease of access for mobile users.

I added the suggested changes, as well the change w/regards to making the embed command part of the JumpView class, as that allowed me to re-work the reply link into a discord UI button instead of the link that it was before.

Looks good to me


Documentation for groups is not working

Describe the bug
Documentation regarding the groups is giving 404 error.
To Reproduce
Steps to reproduce the behavior:

Login to your account
View my groups on your profile dropdown
Click on make group
Click here for documentation
See error

Expected behavior
A documentation should be properly linked and if documentation is not there than it should be made.
Screenshots

Are you working on this issue? (Yes)

@ZaidKhan2002, This is an issue of Circuitverse docs, So Please open this issue in the "CircuitVerseDocs" repo..

I tried, but I am not able to replicate this issue. Instead, the drop-down menu didn't appear when clicking on getting started in the group view page. @vedant-jain03  @pulkit-30 are you able to replicate this issue ?
https://user-images.githubusercontent.com/40604582/152806825-8ce4364b-de68-4367-9361-7fdd5ca45eb2.mp4

No, the mentioned issue didn't exist and the issue with the drop-down menu has been fixed #2739.

@pulkit-30 @Kartikay304 Can we close this issue?

@pulkit-30 @Kartikay304 Can we close this issue?

Sure


How to reload form  again from database saved contents.

How to reload  form again from database saved contents.

store as json or html and simply display in browser

This is not within the scope of this repository

@mbchandar How will you store as Json and pass it in this app.js file >?
Can you show me ?


Proxy/PAC: variable assignment not rendered

via https://forum.opnsense.org/index.php?topic=9905.0;topicseen
I'll fix it when I've time to

fix ready


Mod causes random multiplayer disconnects / crashes.

Friends & randoms report getting booted to main menu or crashing when joining this mod, albeit they don't have the mod(playing with vanilla), but it works for a bit (like we do a couple bosses) then randomly boots them.
Removing the mod completely resolves the issue so yeah...

Hi, thanks for reporting the bug. I didn't test the mod in multiplayer so it might not be multiplayer friendly. I might fix this later.


Add a new icon : tablet

Duplicates ❌

[X] I have searched the existing icons or assets and requests.

Which Figma library is concerned?
Vitamin Icons
Icon or Asset name
tabet
Icon or Asset description
We need to have the tablet icon available in addition to the desktop and mobile icon already present.
Action: Used to change Decathlon preview website to Desktop - Tablet - Mobile on NEMO (Decathlon New E-Merch Operator for Webmarketer).
The remix library version matches perfectly.
Icon or Assets keywords
tablet
Icon or Asset author
https://remixicon.com/
Icon or Asset SVG code
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24"><path fill="none" d="M0 0h24v24H0z"/><path d="M6 4v16h12V4H6zM5 2h14a1 1 0 0 1 1 1v18a1 1 0 0 1-1 1H5a1 1 0 0 1-1-1V3a1 1 0 0 1 1-1zm7 15a1 1 0 1 1 0 2 1 1 0 0 1 0-2z"/></svg>

Are there any other important details?
Request by Louis Bronstein - Product Designer on NEMO

Thanks for your contribution !

Icon published on Figma (in dev libraries to come)

Thx a lot


The menu bar is obscured

A couple more cases where the WCO controls being at the top to the z-order causes this sort of visual glitch:

/duplicate of #160518 and #165454

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Implement view mode toggle

See #72
We have two kind of experiments:

Experimental:

Fragment based
Other PDB

Virtual Screening / Drug Repurposing

Experimental experiments need the following fitlers:

PDB

Virtual Screening need the following filters:

PDB
Binding site

View mode toggle to change between gallery mode and table mode

This is enough for now. Once the viewer migration is done we can review this and discuss how to approach it


Fixed AJAX data separator for select2

select2 needs the separator option to properly parse the AJAX results when using custom data separators, so the separator needs to be propagated to the field.
jQuery 3.5.1 and select2 3.5.2 use separator option, but if select2 is updated the tokenSeparator array option will be needed instead.

Thanks!


Data Warehouse API doesn't return report file to FTP

Hi team,
Starting from 12 Sep we stopped receive report files on FTP via DataWarehouse API. The Report.Queue method return report id and status 200, and checking report status show is everything okay but we didn't gen file to FTP. It's reproducing across multiple report suites within different Adobe organizations. However manual upload to FTP via Experience Cloud UI works fine.  Also, I've tried re-send API call from the UI Request Manager but didn't get success. Below you find all the required information about API requests.
What can be an issue?  Please advise asap.
My API request which was working fine previously
curl --location --request POST 'https://api.omniture.com/admin/1.4/rest/?method=Report.Queue'
--header 'Content-Type: application/json'
--header 'Authorization: Bearer 'xxxxxxxx'
--data-raw '{
"reportDescription": {
"reportSuiteID": "xchmprovtemplcommerce",
"dateFrom": "2020-08-01",
"dateTo": "2020-09-15",
"dateGranularity": "day",
"metrics": [
{
"id": "pageviews"
}
],
"elements": [
{
"id": "browser"
}
],
"source": "warehouse",
"ftp": {
"host": "xxxxxxxxxxx",
"port": "21",
"directory": "adobe_analytics_test",
"username": "xxxxxxxxx",
"password": "xxxxxxxxxxxxxx",
"filename": "Report_arvato_0915.csv"
}
}
}'
Also, I've attached info about the API request from Datawarhouse -> Manager Request page

Hi -- thanks for reporting this issue. We've pushed some code today that should resolve this. Please reopen if this continues to be a problem.
Thanks,
Jared

@stevja1 thank you!
Confirming that's working now.


rename to swift-linux-backtrace

@tanner0101 @weissi @loganwright wdyt?

Couldn't this package be reused in any way on Android, WebAssembly or Windows?

@MaxDesiatov right now the package only works on Linux. further, the goal in general would be to remove the need in such library and make sure you get backtraces oob.
what is the current state of backtraces on Android, WebAssembly or Windows?
cc: @compnerd

Backtraces on Windows should work, as long as you building with debug info (without them, they aren't accurate as expected).  Android backtraces kinda worked when I was working on that port.
+1 for renaming from me (if it means anything).

this was discussed in an SSWG meeting and we decided against naming it now given the fact many projects already depend on it


feat: Error Handling and Rate Limiting

This implements error handling for text analytics exceptions and adds assertions for user errors.

Looks good to me as long as the rate limiting tested & conflicts resolved.


Build fails when duplicate (case-insensitive) file paths are found

Case-sensitive file paths are currently not supported. The conflicting paths detected are 'public/blog/README/index.html' and 'public/blog/Readme/index.html'.

Edited the title a little so that others might find it easier. This is currently a limitation we are working on. We will update this issue when we have more information!

Same issue here... --> Build / Deploy Log: (circa line 200)
Finished building function app with Oryx
Case-sensitive file paths are currently not supported. The conflicting paths detected are 'dist/tag/Development/index.html' and 'dist/tag/development/index.html'.
This is a simple GRIDSOME app build using AZ static web app and GIT actions to build for CI/CD with custom domain (no slots or anything - basic).

We have a fix coming for this soon, will followup once it is out :)

Do you mind retrying? This should be fixed now!


fix: always include vue extension in SFC content paths

In my Nuxt2 app, nuxt.options.extensions is [ 'js', 'mjs' ]. This causes .vue to be excluded from tailwind.
This fix ensures that vue is always added as an extension, but I'm not sure if it's the correct approach. Maybe the options returned by nuxt kit should include it or maybe there is something wrong with my nuxt config? This does slightly change the behavior in that it's no longer possible to exclude vue files from tailwind, but I don't think that's a popular use-case.

Thank you very much for providing feedback on v6.9.x of this module and pointing out an area that we (more of I) missed. I completely agree with you and am happy to merge it soon.
Could I please ask you to configure nuxt.options.extensions to include 'vue' or downgrade to 6.8.1 for a while, as I'd like to give a cooldown period on releases for v6.9, so all bugs can be reported ASAP and we ship them all in 6.9.4 please? (including this fix)

Yes, that's not a problem. I appreciate the quick feedback!


Companion unable to find window with title prefix "title name"(Vivaldi)

Found similar situation in issue #31 and issue #34
But this error only occurs in Vivaldi , Firefox doesn't report this error.

File verbosity level: 9
date       time         ( uptime  ) [ thread name/id ]                   file:line     v|
2021-03-16 00:00:10.986 (   0.003s) [main thread     ]             loguru.cpp:790   INFO| Logging to 'TabFloater Companion\tabfloater-companion.log', mode: 'a', verbosity: 9
2021-03-16 00:00:10.986 (   0.003s) [main thread     ]tabfloater_companion.cp:60    INFO| TabFloater Companion started. Version: 0.9.3, OS: Windows, Git commit: ecb0c95922494a4219d9c960f0d5074742a4ffb6
2021-03-16 00:00:10.986 (   0.003s) [main thread     ]tabfloater_companion.cp:221   INFO| Input JSON: "{"action":"setAsModelessDialog","windowTitle":"TabFloater Options","parentWindowTitle":"New Issue ·tabfloater/tabfloater","debug":"true"}"
2021-03-16 00:00:10.986 (   0.003s) [main thread     ]tabfloater_companion.cp:222   INFO| Action: "setAsModelessDialog"
2021-03-16 00:00:10.986 (   0.003s) [main thread     ]tabfloater_companion.cp:231   INFO| setAsModelessDialog request received
2021-03-16 00:00:10.987 (   0.003s) [main thread     ]tabfloater_companion.cp:235   INFO| Window title: "TabFloater Options"
2021-03-16 00:00:10.987 (   0.003s) [main thread     ]tabfloater_companion.cp:236   INFO| Parent window title: "New Issue · tabfloater/tabfloater"
2021-03-16 00:00:10.987 (   0.004s) [main thread     ]tabfloater_companion.cp:245    ERR| An error occurred while manipulating window: wstring_convert::to_bytes
2021-03-16 00:00:10.987 (   0.004s) [main thread     ]tabfloater_companion.cp:148   INFO| Sending JSON: "{"status":"error"}", length: 18
2021-03-16 00:00:10.988 (   0.004s) [main thread     ]             loguru.cpp:490   INFO| atexit

Hi @learning-and-learning1651880, can you just confirm for me if the following happens:

You press the TabFloater icon in the toolbar
It takes about half a second / second for the floating window to appear
TabFloater shows the above error

Is this what you're seeing? (the delay is an important factor here). If yes, then this is a known issue in Vivaldi. I'm currently working on adding Vivaldi support:
https://github.com/tabfloater/tabfloater/issues/233
This should be released very soon.

Well,it's pretty hard to tell the difference between 0.5s and 1s, but i can feel the loading speed in Chrome(doesn't report error) is faster than in Vivaldi. To check this, i run a script listening my mouse click. Though it's not very precise, can still find a 0.3s-0.5s delay in Vivaldi. ------------------ 原始邮件 ------------------
@.>
发送时间: 2021年3月16日(星期二) 凌晨0:25
@.>;
<EMAIL_ADDRESS>主题: Re: [tabfloater/tabfloater] Companion unable to find window with title prefix "title name"(Vivaldi) (#238)

Okay, that makes sense. https://github.com/tabfloater/tabfloater/issues/233 is already fixed. I will release the new version in the next few days, after that this should work. You will receive a notification from TabFloater once the update has happened.
I'm going to close this, if you still experience problems after you receive the update, please reopen.


Method Illuminate\Support\Number::toCurrency does not exist.

Laravel Version
10.35.0
PHP Version
8.1.0
Database Driver & Version
No response
Description
I tried to use the Number Utility but ran into issues like Undefined type 'Illuminate\Support\Number'. even after upgrading.

Steps To Reproduce
Simply import utility use Illuminate\Support\Number;
Number::toCurrency(1000, 'EUR');

Can you display the output of the following command:
composer show

There's only Number::currency() and not Number::toCurrency(): https://laravel.com/docs/10.x/helpers#method-number-currency

There's only Number::currency() and not Number::toCurrency(): https://laravel.com/docs/10.x/helpers#method-number-currency

Must have been from https://laravel-news.com/laravel-number-utility-class#content-currency-formatting Becsue I did the same thing 😂


[Yubikey-Code] Newline character is appended to clipboard item

Extension
https://www.raycast.com/yoyoyeti/yubikey-code
Description
Newline character is appended to clipboard item. But I think this is more related to the Clipboard API the extension uses.
Steps To Reproduce

Paste the OTP into a text field either manually or via the paste function of the extension

Current Behaviour
See that there is a new line character
Expected Behaviour
I only need the OTP value without the newline

@yoyoyeti Are you not active anymore?

@bin101 I'm Sorry I haven't got back to you about this. Covid took me out the other week, so I've been running behind on a few things. I'll try looking into this soon.

@yoyoyeti works great now, thank you very much 👍


Disable Keyboard when component opens on mobile.

Hello. When I open the component by clicking the Date box, the Mobile Keyboard will opens too! It's a bug I think. Although you use an input to show the date that have picked, but you should disable the keyboard when date box is opened.

Hey thanks
I'm working on a new version of this package, but I don't know when it will be available.
anyway If you want to implement it, feel free to open a PR ☺

thanks for this awesome package ✔✔✔❤. and I'm looking forward for this Improvement too


Add my name to contributors

Please add my name to the contributors list, thank you!

Hi @bguz have you contributed to any of the tutorials so far? Normally people are added when they begin contributing to the GTN.

Hi @bguz have you contributed to any of the tutorials so far? Normally people are added when they begin contributing to the GTN.

Hello,
I only did the Git tutorial, which led me to do the adding of my name in the contributors list.
Thank you,
Beto
Sent from my iPhone

On Jan 4, 2021, at 3:58 AM, Helena Rasche<EMAIL_ADDRESS>wrote:

Hi @bguz have you contributed to any of the tutorials so far? Normally people are added when they begin contributing to the GTN.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hello,
I only did the Git tutorial, which led me to do the adding of my name in the contributors list.
Thank you,
Beto
Sent from my iPhone

On Jan 4, 2021, at 3:58 AM, Helena Rasche<EMAIL_ADDRESS>wrote:

Hi @bguz have you contributed to any of the tutorials so far? Normally people are added when they begin contributing to the GTN.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


refactor for node 6+

If this hasn't been taken on yet, I can take care of it!

@Zertz sure; glad to have the help. i think the primary challenge will be to maintain functionality in the various settings currently supported -- git submodules, and so on.

Are there tests for these special cases?

no, but most of the logic can be see in the git.long code path

This is my code refactoring implementation.
https://github.com/NiceLabs/git-rev


⚠ St. Lawrence Global Observatory CKAN Sitemap has degraded performance

In 0fe5e55, St. Lawrence Global Observatory CKAN Sitemap (https://catalogue.ogsl.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 11231 ms

Resolved: St. Lawrence Global Observatory CKAN Sitemap performance has improved in 4205fa7 after 6 minutes.


feat: expose non-standard components (e.g. Icon, Text, Heading) for solid and vue

I am trying to use Park-UI in new project and followed the steps in the documentation for implementing components such as Heading or Text, but encountered a problem that children won't render properly.
According to Vue Documentation, slots, a.k.a children, are handled slightly differently for vue components (the slots are passed through context variable).
Code samples in Park-UI documentation.
import { styled, type HTMLStyledProps } from 'styled-system/jsx'

type As = 'p' | 'span' | 'div' | 'label'

export type TextProps = {
  as?: As
} & HTMLStyledProps<As>

export const Text = (props: TextProps) => {
  const { as = 'p', ...rest } = props
  const Component = styled(as)

  return <Component {...rest} />
}

Fixed version, passing slots from context parameters to children.
import {
    styled,
    type HTMLStyledProps
} from 'styled-system/jsx'
import type { Events, SetupContext } from 'vue'

type As = 'p' | 'span' | 'div' | 'label'

export type TextProps = {
    as?: As
} & HTMLStyledProps<As>

export const Text = (
    props: TextProps,
    { slots }: SetupContext<Events>
) => {
    const { as = 'p', ...rest } = props
    const Component = styled(as)

    return (
        <Component {...rest}>{slots}</Component>
    )
}

export default Text

I just started using vue and no means a vue expert, but I suppose the code samples needs an update ?
I also created a sample stackblitz to demonstrate both versions just incase.
Thank you very much.

Implemented


Vault Theme

Would it be possible to have the second window apply the vault theme? Or at least a dark mode toggle?

In my testing, second window is applying a dark mode theme in its notes. It will not apply a dark mode to its top status bar, because it's using a system window versus an Obsidian Window.

If you are having issues with it not applying dark mode, there may be some conflicting CSS at play, but the plugin itself fully supports it on its own.


How to exclude files/directories from find-file using ivy

Please visit our Discord server to ask how-to and workflow questions:
https://discord.gg/qvGgnVx -- post on Doom's issue tracker as a last resort.

What are you trying to achieve?
When I hit SPACE SPACE to find file, I want to be able to exclude certain directories from search
What have you tried?
...
I tried adding .projectile to the root of my project with
- /dir
- /dir2

Also per ivy documentation tried adding .ignore to the root with
/dir
/dir2

also tried in my config.el
 (setq projectile-globally-ignored-directories '("dir" "dir2"))

Additional information

Do you have screenshots/casts of this workflow in another editor or Emacs
distro? (If possible, include names of specific commands or functions from
other editors/emacs distros)
Do you have additional material or links to resources that could help clarify
what you are trying to do?

System information

Include the output of `M-x doom/info` or `~/.emacs.d/bin/doom info` here.
```
emacs   version    26.3
        features   XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2
        build      Aug 30, 2019
        buildopts  (--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now)
        windowsys  x
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop, origin/develop, origin/HEAD f9eb6a3b6 2020-02-11 19:24:08 -0500
        dir        ~/.doom.d/
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /usr/bin/zsh
        uname      Linux 5.6.7-arch1-1 #1 SMP PREEMPT Thu, 23 Apr 2020 09:13:56 +0000 x86_64
        path       (~/projects/islands/chat/node_modules/.bin/ ~/.nvm/versions/node/v12.16.1/bin /usr/local/sbin /usr/local/bin /usr/bin /usr/lib/jvm/default/bin /usr/bin/site_perl /usr/bin/vendor_perl /usr/bin/core_perl /usr/lib/emacs/26.3/x86_64-pc-linux-gnu/)
config  envfile    envvar-file
        elc-files  0
        modules    (:completion company ivy :ui deft doom doom-dashboard hl-todo indent-guides modeline nav-flash ophints (popup +all +defaults) treemacs vc-gutter vi-tilde-fringe window-select workspaces :editor (evil +everywhere) file-templates fold multiple-cursors rotate-text snippets :emacs dired electric ibuffer vc :term eshell term :checkers syntax spell :tools debugger docker (eval +overlay) (lookup +docsets) magit :lang data emacs-lisp javascript markdown (org +dragndrop +jupyter +present) python sh web :email (mu4e +gmail) :app irc :config (default +bindings +smartparens))
        packages   ((treemacs-magit) (treemacs-icons-dired) (winum) (ob-prolog))
        elpa       (org-plus-contrib ob-prolog memoize android-mode all-the-icons)
        unpin      (n/a)
```

.ignore files should work. With
dir/
dir2/

In it. Not sure if the leading / is the issue here, but as long as you have ripgrep or fd installed, it will obey ignore files.

Not working... Tried also without leading / and with trailing /.

Odd. It works fine for me, in vanilla Doom, using either ripgrep or fd.
What's the value of projectile-generic-command and projectile-git-command? (Use SPC h v name-of-variable to check).

projectile-generic-command
"rg -0 --files --color=never --hidden --glob '!~/.emacs.d/.local/' --glob '!.idea' --glob '!.ensime_cache' --glob '!.eunit' --glob '!.git' --glob '!.hg' --glob '!.fslckout' --glob '!_FOSSIL_' --glob '!.bzr' --glob '!_darcs' --glob '!.tox' --glob '!.svn' --glob '!.stack-work'"

projectile-git-command
"rg -0 --files --color=never --hidden --glob '!~/.emacs.d/.local/' --glob '!.idea' --glob '!.ensime_cache' --glob '!.eunit' --glob '!.git' --glob '!.hg' --glob '!.fslckout' --glob '!_FOSSIL_' --glob '!.bzr' --glob '!_darcs' --glob '!.tox' --glob '!.svn' --glob '!.stack-work'"

Oh, perhaps what you're seeing is the cache. Press SPC p i or SPC u SPC SPC to refresh the cache.

Oh, perhaps what you're seeing is the cache. Press SPC p i or SPC u SPC SPC to refresh the cache.

Thank you Henrik, that was it. I've realized that ripgrep was not installed after all, I was confused by presence of projectile-ripgrep function assuming that ripgrep is also installed.
I've installed ripgrep, then invalidated project cache and re-opened the project.
My .ignore file looks like this:
dir1
dir2

Now all is working as expected.
And thanks for developing Doom Emacs, I just love it!


Add documentation for the HTTPScaledObject schema

We only have the code and example YAML at the moment. We should document this much better in the repo

Happy to review it along with a sample!

@tomkerkhove I can create an initial version and upload it here so we have all the docs ready, then we can change it when we update

That's fine for me! But for me it's ok if it's in the repo already and we change it there as well.

I added a reference for it in https://github.com/kedacore/http-add-on/pull/78 - sorry I forgot to tab this issue in there!


Automated notification for invoice payment

Describe the task
Currently, we don't have any automated notification system feature which tells us that the invoice for a particular project is being paid.
Expected behavior

[ ] We need a automated notification system telling us that an invoice for  particular project is being paid through project channel.

[ ] The content for that notification can be:

For Project :- @all We have received the payment for {project-name} successfully!
For Client :- @all We have received the payment for {client-project-name} successfully!

The requirement looks fine @Gauravchamoli1997. Can you also add the breakdown of action items that you will be performing

The requirement looks fine @Gauravchamoli1997. Can you also add the breakdown of action items that you will be performing

@GauravGusain98 Thanks. As I do this task, I will keep adding action items to the breakdown that I will perform.

Testing Feedbacks
This is what we received on channel when we tested this feature. The invoice details is being displayed


Add option to mute stderr

In Nushell, I used do -i { git ... } to fetch my git statistics and relied on the fact that do -i mutes the stderr. In engine-q, it still leaks the stderr output of the external command.
Reproduce:

cd  # any directory that is not a git repo
do -i { git status }

observe error message

I'm not sure if do -i should mute stderr but we should have some way to do it. To expand on this, we could have a command to selectively filter out stdout, stderr, or both.

it leaks in nushell too see https://github.com/nushell/nushell/issues/3541. I agree, I'd totally like to have this fixed.

possible dupe with #567


Clean memory leaks

I had a quick run through, there are retain issues in/related to Sign Up
Switch to Sign Up then close Lock.
Quick way to test vs profiler is with a deinit to DatabasePresenter.swift
deinit {
  print("dealloc DatabasePresenter")
}

Also check after inputting in fields.


Add PE RBAC token support

Puppet Enterprise RBAC allows for token-based authentication to PuppetDB. This enables token-based authentication and also enables automatic configuration of PuppetDB based on the PE Client Tools configuration files, which are likely to be found on any system using token-based authentication.

thanks for the PR!


Hardware variant with 5k resistor in input circuit

@BigVulcanDeal wrote about an incompatible hardware variant he received that has a 5k instead of a 20k resistor in the input circuit. Although 5k is a better match for temperatures in the 30 ... 50°C range it of course requires a different linearization table.

Most recently at least 4 W1209 clones have been reported: unfortunately one of them is 8051 based, and thus completely incompatible with STM8 eForth (unless you replace the µC).
Please refer to the following information:

STM8 eForth Wiki (thanks to @VK6TT)
TG9541/stm8ef Issue #153
TG9541/stm8ef Issue #156

see also discussion in issue #22


Validate and test packages

Description
We have developed tools to generate packages of wazuh-indexer from a given commit of this repository. In order to verify that these packages are worthy, we need to validate their contents and test them.
Use previous tests as a guideline.

https://github.com/wazuh/wazuh/issues/20703

Tasks
For assembled RPM and DEB packages generated using our tools, we need to:

[ ] Validate their content. We expect the packages to contain the same amount of files as in previous packages of wazuh-indexer (4.7.0).
[ ] Test the packages' lifecycle. We expect the packages to upgrade, install and uninstall successfully. Moreover, wazuh-indexer must work without errors.

Test requirements and restrictions
During the packages' validation step, download and extract the fork (4.9.0) and pre-fork (4.7.0) packages for the same distribution (deb / rpm), and compare its contents. An example of this procedure can be seen here.
If you find differences in their contents, note them as follows:

New files represent a Warning.
Missing files represent a Failure.

It is not required to verify the content of the files themselves, but do check important configuration files as /etc/wazuh-indexer/jvm.options and /etc/wazuh-indexer/opensearch.yml.
For the packages' testing step, download and install the fork (4.9.0) and pre-fork packages (4.7.0) and test that:

Following the upgrade guide, wazuh-indexer upgrades from 4.7.0 to 4.9.0 successfully, meaning there are no errors in the logs, the service is active, and the cluster is in green state (see the notes below for more information).
Following the uninstallation guide, wazuh-indexer and all its contents are removed from the system.
Following the installation guide, wazuh-indexer installs, meaning there are no errors in the logs, the service is active, and the cluster is in green state (see the notes below for more information).
For the installation, do also check file permissions.

Legend

🟢
Success

🟠
Warning

🔴
Failure

Notes

logs: /var/log/wazuh-indexer/wazuh-cluster.log
journalctl: journalctl -xeu wazuh-indexer
service: systemctl status wazuh-indexer
cluster state: curl -X PUT "https://<WAZUH_INDEXER_IP>:9200/_cluster/health" -u <username>:<password>
For the installation, the addition of the Wazuh repository can be skipped. Install the package directly (yum localinstall <path-to-package> or dpkg -i <path-to-package>).

.deb Packages validation:
Dependency changes:

Name
Status
Old Version
New Version

adduser
removed

debconf
removed

procps
removed

libasound2
added

>= 1.0.16

libc6
added

>= 2.9

libfreetype6
added

>= 2.3.5

libx11-6
added

libxext6
added

libxi6
added

libxrender1
added

libxtst6
added

zlib1g
added

>= 1.2.2

.rpm Packages validation:
Shared libraries:

Name
Status
Delta
Visual Diff

/usr/share/wazuh-indexer/plugins/opensearch-knn/lib/libgomp.so.1
removed

/usr/share/wazuh-indexer/plugins/opensearch-knn/lib/libopensearchknn_common.so
removed

/usr/share/wazuh-indexer/plugins/opensearch-knn/lib/libopensearchknn_faiss.so
removed

/usr/share/wazuh-indexer/plugins/opensearch-knn/lib/libopensearchknn_nmslib.so
removed

Shell Programs:

Name
Status
Delta
Visual

Diff

/usr/share/wazuh-indexer/plugins/opensearch-security/tools/install_demo_configuration.sh
added

/usr/share/wazuh-indexer/bin/indexer-ism-init.sh
added

/usr/share/wazuh-indexer/bin/indexer-init.sh
added

/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh
removed

/usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-certs-tool.sh
removed

Configuration files:

Name
Status
Delta
Visual Diff

/var/lib/wazuh-indexer/performance_analyzer_enabled.conf
added

/var/lib/wazuh-indexer/rca_enabled.conf
added

Symbolic Links:

Name
Status
Delta
Visual Diff

/usr/share/wazuh-indexer/data
added

/usr/share/wazuh-indexer/logs
added

Policy Files:

Name
Status
Delta
Visual Diff

/usr/share/wazuh-indexer/plugins/opensearch-geospatial/plugin-security.policy
added

YAML Files:

Name
Status
Delta
Visual Diff

/usr/share/wazuh-indexer/plugins/opensearch-security/tools/config.yml
removed

Directories:

Name
Status

/var/run
added

/var/run/wazuh-indexer
added

/usr/share/wazuh-indexer/plugins/opensearch-knn/lib
removed

Archives:

Name
Status
Delta
Visual

Diff

/usr/share/wazuh-indexer/lib/jakarta.annotation-api-1.3.5.jar
added

/usr/share/wazuh-indexer/lib/jzlib-1.1.3.jar
added

/usr/share/wazuh-indexer/lib/opensearch-common-2.11.1.jar
added

/usr/share/wazuh-indexer/lib/opensearch-compress-2.11.1.jar
added

/usr/share/wazuh-indexer/lib/opensearch-core-2.11.1.jar
added

/usr/share/wazuh-indexer/lib/opensearch-telemetry-2.11.1.jar
added

/usr/share/wazuh-indexer/lib/zstd-jni-1.5.5-5.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/byte-buddy-1.9.0.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/byte-buddy-agent-1.9.0.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/jakarta.activation-2.0.0.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/jakarta.annotation-api-1.3.5.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/jakarta.xml.bind-api-3.0.0.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/jooq-3.16.20.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/mockito-core-2.23.0.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/objenesis-2.6.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/r2dbc-spi-0.9.0.RELEASE.jar
added

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/reactive-streams-1.0.3.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-alerting/kotlin-stdlib-jdk7-1.8.21.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-alerting/kotlin-stdlib-jdk8-1.8.21.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-anomaly-detection/randomcutforest-parkservices-3.8.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-cross-cluster-replication/kotlin-stdlib-jdk7-1.8.21.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-cross-cluster-replication/kotlin-stdlib-jdk8-1.8.21.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-geospatial/commons-csv-1.10.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-geospatial/ipaddress-5.4.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-geospatial/opensearch-geospatial-<IP_ADDRESS>.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-job-scheduler/google-java-format-1.17.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/accessors-smart-2.4.9.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/annotations-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/apache-client-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/asm-9.3.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/auth-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/aws-encryption-sdk-java-2.4.1.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/bcprov-ext-jdk18on-1.75.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/endpoints-spi-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/eventstream-1.0.1.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/http-client-spi-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/httpcore5-5.2.1.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/json-20231013.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/json-path-2.8.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/json-utils-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/metrics-spi-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/opensearch-ml-memory-<IP_ADDRESS>.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/opensearch-ml-search-processors-<IP_ADDRESS>.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/profiles-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/reactive-streams-1.0.3.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/regions-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/sdk-core-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/third-party-jackson-core-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-ml/utils-2.20.19.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-neural-search/commons-text-1.10.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-neural-search/gson-2.10.1.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-neural-search/json-20230227.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-neural-search/opensearch-neural-search-<IP_ADDRESS>.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security-analytics/google-java-format-1.17.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security-analytics/guava-32.0.1-jre.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security/commons-io-2.13.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security/commons-lang3-3.13.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security/google-java-format-1.17.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security/json-base-2.4.3.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security/passay-1.6.4.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-security/scala-java8-compat_3-1.0.2.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/aws-java-sdk-emr-1.12.545.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/aws-java-sdk-emrserverless-1.12.545.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/commons-beanutils-1.9.4.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/commons-digester-2.1.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/commons-validator-1.7.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/ipaddress-5.4.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/kotlin-stdlib-jdk7-1.9.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/kotlin-stdlib-jdk8-1.8.0.jar
added

/usr/share/wazuh-indexer/plugins/opensearch-sql/spark-<IP_ADDRESS>.jar
added

/usr/share/wazuh-indexer/jdk/lib/jrt-fs.jar
changed
0.001%

/usr/share/wazuh-indexer/plugins/opensearch-security/commons-collections-3.2.2.jar
moved
0%

/usr/share/wazuh-indexer/plugins/opensearch-sql/commons-collections-3.2.2.jar
moved
0%

/usr/share/wazuh-indexer/plugins/opensearch-security/json-smart-2.4.10.jar
moved
0%

/usr/share/wazuh-indexer/plugins/opensearch-ml/json-smart-2.4.10.jar
moved
0%

/usr/share/wazuh-indexer/lib/hppc-0.8.1.jar
removed

/usr/share/wazuh-indexer/lib/opensearch-common-2.8.0.jar
removed

/usr/share/wazuh-indexer/lib/opensearch-core-2.8.0.jar
removed

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/j2objc-annotations-1.3.jar
removed

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/javax.annotation-api-1.3.2.jar
removed

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/jooq-3.10.8.jar
removed

/usr/share/wazuh-indexer/performance-analyzer-rca/lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-alerting/kotlin-stdlib-jdk7-1.6.10.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-alerting/kotlin-stdlib-jdk8-1.6.10.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-anomaly-detection/randomcutforest-parkservices-3.0-rc3.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-cross-cluster-replication/kotlin-stdlib-jdk7-1.6.0.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-cross-cluster-replication/kotlin-stdlib-jdk8-1.6.0.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-geospatial/opensearch-geospatial-<IP_ADDRESS>.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-neural-search/opensearch-neural-search-<IP_ADDRESS>.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-performance-analyzer/j2objc-annotations-1.3.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-performance-analyzer/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-security/commons-lang-2.4.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-security/jakarta.annotation-api-1.3.5.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-security/json-path-2.4.0.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-security/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-security/zstd-jni-1.5.2-1.jar
removed

/usr/share/wazuh-indexer/plugins/opensearch-sql/kotlin-stdlib-jdk7-1.4.30.jar
removed

.deb package install:
Errors are thrown during installation on Ubuntu 22.04:
/usr/lib/tmpfiles.d/wazuh-indexer.conf:1: Failed to resolve user 'wazuh-indexer': No such process
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
Processing triggers for man-db (2.10.2-1) ...
needrestart is being skipped since dpkg has failed

Trying to start the service fails:
Jan 05 15:57:10 pkg-tests-ubuntu2204 systemd[1]: Starting wazuh-indexer...
Jan 05 15:57:10 pkg-tests-ubuntu2204 systemd[28927]: wazuh-indexer.service: Failed to determine user credentials: No such process
Jan 05 15:57:10 pkg-tests-ubuntu2204 systemd[28927]: wazuh-indexer.service: Failed at step USER spawning /usr/share/wazuh-indexer/bin/systemd-entrypoint: No such process
Jan 05 15:57:10 pkg-tests-ubuntu2204 systemd[1]: wazuh-indexer.service: Main process exited, code=exited, status=217/USER
Jan 05 15:57:10 pkg-tests-ubuntu2204 systemd[1]: wazuh-indexer.service: Failed with result 'exit-code'.
Jan 05 15:57:10 pkg-tests-ubuntu2204 systemd[1]: Failed to start wazuh-indexer.

.rpm package install:
Install throws errors on Alma Linux 8 as well:
[root@alma8 ~]# rpm -i wazuh-indexer-4.9.0-1.x86_64.rpm
warning: %post(wazuh-indexer-4.9.0-1.x86_64) scriptlet failed, exit status 255
[/usr/lib/tmpfiles.d/wazuh-indexer.conf:1] Line references path below legacy directory /var/run/, updating /var/run/wazuh-indexer → /run/wazuh-indexer; please update the tmpfiles.d/ drop-in file accordingly.

Issues than open from this testing:

https://github.com/wazuh/wazuh-indexer/issues/101
https://github.com/wazuh/wazuh-indexer/issues/102
https://github.com/wazuh/wazuh-indexer/issues/103
https://github.com/wazuh/wazuh-indexer/issues/104
https://github.com/wazuh/wazuh-indexer/issues/105
https://github.com/wazuh/wazuh-indexer/issues/106
https://github.com/wazuh/wazuh-indexer/issues/107
https://github.com/wazuh/wazuh-indexer/issues/108

Current testing iteration of<EMAIL_ADDRESS>packages concluded with errors.
We'll work on these issues and open a new testing iteration.


One tiny typo in the first §

Coverage decreased (-0.9%) to 96.092% when pulling 7b294e867e6433025a3ea10ea466ae91b14eb204 on Naereen:patch-1 into fdcd142f9e578080d3df3602a3a5f8acc0b43cec on has2k1:master.

Thanks.


issue using rake

changed https://github.com/rspec/rspec-core/blob/master/lib/rspec/core/rake_task.rb#L111 to
desc "Run RSpec code examples unless ::Rake.application.last_comment"
to run this Rakefile. commit is https://github.com/rspec/rspec-core/commit/e894c641d10435765f2b0ed3a07c5ac652db534f
rake lexer works now, no messages.
require 'rspec/core/rake_task'

RSpec::Core::RakeTask.new do |c|
  options = ['--color']
  options += ["--format", "documentation"]
  c.rspec_opts = options
end

desc "Generate Lexer"
task :lexer do
  `rex test_language.rex -o lexer.rb`
end

ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x64-mingw32]
faced it while working through rexical wiki.
thanks. have a nice day. keep up the great work. 👏
ret394

@marcandre would you like to take a look? Seems related to what you've been working on here already.

Can you provide the error you are seeing?

With rspec-core (3.9.1) and your Rakefile I see no errors from rspec.
 Interrupt again to force quit.
  is expected to eq 2866
rake aborted!

Finished in 0.66632 seconds (files took 0.5805 seconds to load)
2867 examples, 0 failures

$ bundle exec rake lexer
rake aborted!
Errno::ENOENT: No such file or directory - rex
/Users/bti/code/rspec-dev/repro-scripts/Rakefile:11:in ``'
/Users/bti/code/rspec-dev/repro-scripts/Rakefile:11:in `block in <top (required)>'
/Users/bti/.rvm/gems/ruby-2.7.1/bin/ruby_executable_hooks:24:in `eval'
/Users/bti/.rvm/gems/ruby-2.7.1/bin/ruby_executable_hooks:24:in `<main>'
Tasks: TOP => lexer
(See full trace by running task with --trace)

I don't see anything either but there is a discrepancy with that method between rake versions, we might need to conditionally define something, or maybe we should just recommend updating Rake, IDK.

I tried with rake 10.2.2 from 2014 https://github.com/ruby/rake/releases/tag/v10.2.2 and it's still working. There is deprecation warnings but commands are working.
Without further information. The issue could be closed.

There is deprecation warnings but commands are working.

I suspect this is what they were seeing, is it from us or rake?

Sorry I was testing with last released rspec-core. Not master. Let me switch. :)

#Gemfile
source 'https://rubygems.org'

gem 'rake', '10.2.2'

group :development, :test do
  %w[rspec-core rspec-expectations rspec-mocks rspec-support].each do |lib|
    gem lib, git: "https://github.com/rspec/#{lib}.git", branch: 'master'
  end
end

Rake file from OP. I tried rake 13.0.1 the last released version and 'rake', '10.2.2' from 2014 and no breaking issues.
If we use for example rake 11.3.0. There is deprecation warnings like:
/Users/bti/.rvm/gems/ruby-2.7.1/gems/rake-11.3.0/lib/rake/application.rb:378: warning: deprecated Object#=~ is called on Proc; it always returns nil

But on all rake commands.
You need at least gem 'rake', '~> 12.3.0' to avoid deprecation warnings.


Moving pthread_create() related code into a generic thread creation function/file.

Current coverage is 11.11% (diff: 100%)

Merging #28 into master will not change coverage

@@             master        #28   diff @@
==========================================
  Files             1          1
  Lines            45         45
  Methods           0          0
  Messages          0          0
  Branches          8          8
==========================================
  Hits              5          5
  Misses           39         39
  Partials          1          1

Powered by Codecov. Last update c8280b7...409462c


Remove library-go replaces and update clients.go for k8s 1.31

/lgtm

Supersedes https://github.com/openshift/cluster-olm-operator/pull/76

/retest

/retest

/retitle  NO-ISSUE: Remove library-go replaces and update clients.go for k8s 1.31


Add SignoutCallbackComponent

I have duplicated the CallbackComponent into a new SignoutCallbackComponent so that there is a component to handle the signout redirect process.
CallbackComponent could potentially support both in one component by accepting a method prop which could be signoutRedirect or signinRedirect but that would be a breaking change.

This has been published to version  3.1.0.Thank you!
I also like the separation into two different components more than using the CallbackComponent. This way, should further complexity be needed for either down the road, there are two separate components to work with.


LinqToExcel in transaction scope

I got InvalidOperationException when invoking your awesome library in transaction scope "ITransactionLocal interface is not supported". I can't solve this issue by extracting piece of code outside of transaction due to architecture.
Found solution on SO, but your API doesn't allow to change connection string.
http://stackoverflow.com/questions/19387695/error-the-itransactionlocal-interface-is-not-supported-by-the-microsoft-ace-o
Can you add some extra parameter to constructor or just add this parameter by default to connection string ?

Seconding this request.
One solution might be to allow arbitrary additions to the connection string via the ExcelQueryFactory, or allowing a ReadOnly access to also specify OLE DB Services=-4 in the query string, which will exclude the connection from pooling and automatic translation enlistment. The former is probably a bit more flexible.

Bump... Also getting this error as well.
I found that someone had a workaround from #15  but I can't find the workaround.
https://github.com/paulyoder/LinqToExcel/issues/15
Seems this issue still not being fixed after 2 years?

As Paul said in issue #15 to the user there, what is the use case? What are you trying to accomplish using transaction scopes?

My use case was creating a transaction scope for a bunch of database transactions that I wanted to tie together (an import from Excel where they all import or none do). However, because I'm processing the Excel file at the same time, LinqToExcel gets caught up in the transaction mechanism and the error occurs.
If I was able to mark the Excel data source as read only, or was able to specify OLD DB Services=-4 in the connection string to the Excel file, then it would not get picked up by the transaction scope.


Card titles not showing on timeline?

Describe the bug
I created a vertical timeline and passed in an items object of cards with title, cardTitle, and cardSubtitle. The timeline and cards are showing correctly, but the titles are not showing.
To Reproduce
I just used the "getting started" code snippet".
Expected behavior
I expected to see titles appear on the left side of the timeline to correspond with each card.
Screenshots

Desktop (please complete the following information):

OS: macOS Catalina
Browser: Chrome
Version: 87.0.4280.67

@derekxiao77 thanks for reporting the issue. this is now fixed. please check and let me know if you are still facing any issues.

It's fixed now, thank you! Is it possible to control the font of the title and card text without custom rendering?

there is no font specific setting right now. ideally the component should  inherit the fonts from the container (if you have set one).
is this not working already


crash when deleting multiple files

Just noticed a crash when deleting 2 selected files at the same time.  on windows 7.  Haven't tried duplicating it or anything, but if you need a log or something let me know.

Closing this out since it was reported as going away and more details aren't available at this time. Please comment if you see this again on Atom 1.0.3+.


Fixed method lookup for pushUniqueWithGuid

The lookup logic stepped over every second method entry which
lead to the same method being added multiple times if the
existing entries happen to reside at odd indexes in the
targetQueue array.
Signed-off-by: Christian Gudrian<EMAIL_ADDRESS>

Can you add a test that fails on master, but this fixes?  To help prevent future regressions...

Should I open a second pull request for the failing test?

Nah, just go ahead and add it to this one.

Good catch. Failed refactoring likely my fault. Lets get s test in

Test case added.

wait, let me noodle on this again later. Something is fishy

we need to slide this into ember now.