Connection reset from long-running or stale API connections

Describe the bug
As we've used the openai.ChatCompletion.create (with gpt-3.5-turbo), we've had intermittent
requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))

without a clear reproduction. At first I thought it was https://github.com/openai/openai-python/issues/91 and due to too many open connections to the OpenAI servers. Now I think it looks more like https://github.com/openai/openai-python/issues/368 instead, but I have some hypotheses about it. I'm opening a new issue separate from https://github.com/openai/openai-python/issues/368 in case they're different. If this is a duplicate, we can feel free to tack on my details there.
My hypothesis is that if you have a long running process (like a web server), and it calls out to OpenAI, that periods of inactivity cause the server side to terminate the connection and it takes a long time for the client to reestablish the connection. I dug into related issues on the requests side (like this one, https://github.com/psf/requests/issues/4937) that hinted at the root cause. Essentially, what I think is happening is that,

First connection is made to OpenAI, returns a result, requests maintains a connection under the hood with default keep-alive
some time passes, in my experience, around 10 minutes should do
New connection is made to OpenAI, but the client throws a ConnectionResetError

A new call after this succeeds

I believe that the OpenAI servers are terminating the connection after a brief time (perhaps minutes) but the client still tries to keep it alive.
The reason why I think this is a bug worth reporting is that I think you could modify the client code so it responds more gracefully to these server-side settings. Changing some of the keep-alive settings from the default ones would help out several folks using this.
To Reproduce

Write a long-running program. In our case, we have a Python web server running FastAPI
As part of a route for the server, call OpenAI to do some work. In our case, we're calling openai.ChatCompletion.create with gpt-3.5-turbo to manipulate some input language and respond back with it
Run the server and call the endpoint once
Wait 10 minutes
Call the endpoint again
You'll likely get a Connection reset by peer issue on the second call

Code snippets
No response
OS
Linux
Python version
Python v3.8
Library version
openai-python 0.27.2

i am experiencing the same issue, also using FastAPI

Seeing the above issue intermittently in a local Jupyter notebook.
Error:
File /opt/homebrew/lib/python3.11/site-packages/openai/api_requestor.py:529, in APIRequestor.request_raw(self, method, url, params, supplied_headers, files, stream, request_id, request_timeout)
    527     raise error.Timeout("Request timed out: {}".format(e)) from e
    528 except requests.exceptions.RequestException as e:
--> 529     raise error.APIConnectionError(
    530         "Error communicating with OpenAI: {}".format(e)
    531     ) from e
    532 util.log_debug(
    533     "OpenAI API response",
    534     path=abs_url,
   (...)
    537     request_id=result.headers.get("X-Request-Id"),
    538 )
    539 # Don't read the whole stream for debug logging unless necessary.

APIConnectionError: Error communicating with OpenAI: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

Main function:
def get_completion(prompt, model="gpt-3.5-turbo"):
    messages = [{"role": "user", "content": prompt}]
    response = openai.ChatCompletion.create(
        model=model,
        messages=messages,
        temperature=0, # this is the degree of randomness of the model's output
    )
    return response.choices[0].message["content"]

Full stacktrace:
jp-nb-apiconnectionerror.log

I am having the same issue. Making an API call and then waiting for 30 minutes before calling again results in: openai.error.APIConnectionError: Error communicating with OpenAI: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

This is my workaround, I just wrap all of my OpenAI function calls inside this:
async with ClientSession() as s:
     openai.aiosession.set(s)
     response = await openai.Completion.acreate( ...

Could you please help me understand why my attempt to apply that to an embedding function throws an error?
async def process_inputs(inputs, model_id="text-embedding-ada-002"):
embeddings = []

async with aiohttp.ClientSession() as s:
    openai.aiosession.set(s)
    for sentence in inputs:
        response = await openai.Embedding.create(
            engine=deployment_id,
            model=model_id,
            input=sentence,
            max_tokens=100,
            temperature=0
        )
        embeddings.append(response['data'][0]['embedding'])
return embeddings

Result:
TypeError: object OpenAIObject can't be used in 'await' expression

Could you please help me understand why my attempt to apply that to an embedding function throws an error?
'''
async def process_inputs(inputs, model_id="text-embedding-ada-002"):
embeddings = []

async with aiohttp.ClientSession() as s:

    openai.aiosession.set(s)

    for sentence in inputs:

        response = await openai.Embedding.create(

            engine=deployment_id,

            model=model_id,

            input=sentence,

            max_tokens=100,

            temperature=0

        )

        embeddings.append(response['data'][0]['embedding'])

return embeddings

'''
embeddings = await process_inputs(df['openai'].tolist())
Result:
TypeError: object OpenAIObject can't be used in 'await' expression

It needs to be wrapped in an async function first, and then you can call it using asyncio

It is an async function, but github Is not formatting that first line right

If anyone is looking for a workaround that does not requiring changing to async, the following is working for us.  It's the same idea as hc20k's workaround above: https://github.com/openai/openai-python/issues/371#issuecomment-1537622984
Using the support added in v0.27.6 to pass in a session we do the following:
        # Pass a new session to the openai module
        openai.requestssession = requests.Session()

        # Existing code calling openai
        response = openai.Completion.create(...)

        # Close and reset the session
        try:
            openai.requestssession.close()
        except Exception as e:
            logging.exception(e)
        openai.requestssession = None

There may be more elegant ways to do this, but in our testing we are no longer seeing the errors on long-running (web app) threads that make openai calls.

@turnham It'll do the job but one thing you might miss out on is potential speed improvements by reusing persistent connections. The requests docs on Sessions explain this briefly and link to the basic idea. I still think that since OpenAI knows their own server configurations, if they modify the keep-alive settings, that'll have the most improvement on community use.
In my own case, I switched over to using tenacity, since the OpenAI docs recommend it.
@retry(
    stop=stop_after_attempt(2),
    retry=retry_if_exception_type(openai.error.APIConnectionError),
)
def call_openai():
    ...

@mathcass +1.  Yes it would be great if the openai module would take care of all of this.
I don't think your approach with tenacity retries would have helped with our situation though.  Once we had a long running thread get into this state, all retries would fail. So to get that use case working consisently, we had to force the resetting openai's _thread_context.session, by making sure a cached session was never present to be re-used:
https://github.com/openai/openai-python/blob/fe3abd16b582ae784d8a73fd249bcdfebd5752c9/openai/api_requestor.py#L79
But also adding retries sounds like something we should be doing regardless of this issue, so thanks for the pointers to tenacity!

Just to add for anybody who comes looking I have this problem when I'm using a VPN, not sure why.    I am outside the US by the way.

The same error was confirmed when using Azure OpenAI's gpt-3.5-turbo. Changing the model version from 0301 to 0601 resolved the issue. Anyone in the same situation may want to try this.

@turnham so we can say the openai client is not thread safe since the openai.requestssession is global and can be changed in each thread. Is my understanding right?

@pamelafox Since you seem to be the most well versed with this issue - I'd like to ask, should this now work with the openai-python client? I ran into this issue using long running mapreduce calls in langchain. The error I would see is a aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed and langchain doesn't retry on it.
It typically happens after my client has sent a request to 3.5-turbo-16k (openai) but with a large number of input tokens (10-12k) and after 2-3 minutes it gives me this error, bills me, and I don't end up with a generation.
body="<StreamReader e=ClientPayloadError('Response payload is not completed')>" message='Response payload is not completed'
body="<StreamReader e=ClientPayloadError('Response payload is not completed')>" message='Response payload is not completed'
Traceback (most recent call last):
  File "/pkg/modal/_container_entrypoint.py", line 352, in handle_input_exception
    yield
  File "/pkg/modal/_container_entrypoint.py", line 510, in run_input
    value = await res
  File "/root/reports.py", line 172, in analyze_document_summarize_llm_chain
    res = await chain.acall(inputs={'input_documents': texts}, return_only_outputs=True)
  File "/usr/local/lib/python3.9/site-packages/langchain/chains/base.py", line 361, in acall
    raise e
  File "/usr/local/lib/python3.9/site-packages/langchain/chains/base.py", line 355, in acall
    await self._acall(inputs, run_manager=run_manager)
  File "/usr/local/lib/python3.9/site-packages/langchain/chains/combine_documents/base.py", line 121, in _acall
    output, extra_return_dict = await self.acombine_docs(
  File "/usr/local/lib/python3.9/site-packages/langchain/chains/combine_documents/map_reduce.py", line 240, in acombine_docs
    map_results = await self.llm_chain.aapply(
  File "/usr/local/lib/python3.9/site-packages/langchain/chains/llm.py", line 209, in aapply
    raise e
  File "/usr/local/lib/python3.9/site-packages/langchain/chains/llm.py", line 206, in aapply
    response = await self.agenerate(input_list, run_manager=run_manager)
  File "/usr/local/lib/python3.9/site-packages/langchain/chains/llm.py", line 115, in agenerate
    return await self.llm.agenerate_prompt(
  File "/usr/local/lib/python3.9/site-packages/langchain/chat_models/base.py", line 424, in agenerate_prompt
    return await self.agenerate(
  File "/usr/local/lib/python3.9/site-packages/langchain/chat_models/base.py", line 384, in agenerate
    raise exceptions[0]
  File "/usr/local/lib/python3.9/site-packages/langchain/chat_models/base.py", line 485, in _agenerate_with_cache
    return await self._agenerate(
  File "/usr/local/lib/python3.9/site-packages/langchain/chat_models/openai.py", line 425, in _agenerate
    response = await acompletion_with_retry(
  File "/usr/local/lib/python3.9/site-packages/langchain/chat_models/openai.py", line 92, in acompletion_with_retry
    return await _completion_with_retry(**kwargs)
  File "/usr/local/lib/python3.9/site-packages/tenacity/_asyncio.py", line 88, in async_wrapped
    return await fn(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/tenacity/_asyncio.py", line 47, in __call__
    do = self.iter(retry_state=retry_state)
  File "/usr/local/lib/python3.9/site-packages/tenacity/__init__.py", line 314, in iter
    return fut.result()
  File "/usr/local/lib/python3.9/concurrent/futures/_base.py", line 439, in result
    return self.__get_result()
  File "/usr/local/lib/python3.9/concurrent/futures/_base.py", line 391, in __get_result
    raise self._exception
  File "/usr/local/lib/python3.9/site-packages/tenacity/_asyncio.py", line 50, in __call__
    result = await fn(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/langchain/chat_models/openai.py", line 90, in _completion_with_retry
    return await llm.client.acreate(**kwargs)
  File "/usr/local/lib/python3.9/site-packages/openai/api_resources/chat_completion.py", line 45, in acreate
    return await super().acreate(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/openai/api_resources/abstract/engine_api_resource.py", line 217, in acreate
    response, _, api_key = await requestor.arequest(
  File "/usr/local/lib/python3.9/site-packages/openai/api_requestor.py", line 382, in arequest
    resp, got_stream = await self._interpret_async_response(result, stream)
  File "/usr/local/lib/python3.9/site-packages/openai/api_requestor.py", line 729, in _interpret_async_response
    (await result.read()).decode("utf-8"),
  File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 1037, in read
    self._body = await self.content.read()
  File "/usr/local/lib/python3.9/site-packages/aiohttp/streams.py", line 349, in read
    raise self._exception
  File "/usr/local/lib/python3.9/site-packages/openai/api_requestor.py", line 722, in _interpret_async_response
    await result.read()
  File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 1037, in read
    self._body = await self.content.read()
  File "/usr/local/lib/python3.9/site-packages/aiohttp/streams.py", line 375, in read
    block = await self.readany()
  File "/usr/local/lib/python3.9/site-packages/aiohttp/streams.py", line 397, in readany
    await self._wait("readany")
  File "/usr/local/lib/python3.9/site-packages/aiohttp/streams.py", line 304, in _wait
    await waiter
aiohttp.client_exceptions.ClientPayloadError: Response payload is not completed

In the latest version i.e 0.28.0, you can also pass a request_timeout = <timeout in sec> and have the session closed after the timeout.

@microsoftbuild Looks like this issue could bring up issues again, wrt OP: https://github.com/openai/openai-python/pull/387

@ShantanuNair In that case, you could use a request_timeout = <timeout in sec> param in the following workaround suggested by @turnham :
with requests.Session() as session:
    openai.requestssession = session
    response = openai.Completion.create(...)
    openai.requestssession = None

@microsoftbuild See this

I then tried specifying a request_timeout parameter for the OpenAI API request, but that caused every request to timeout, due to this issue:
https://github.com/openai/openai-python/pull/387

This should be fixed in the beta of our upcoming v1.0.0; can you try it out and let us know whether or not it seems to be resolved?


ISPN-6435 Protect REST delete from throwing error

https://issues.jboss.org/browse/ISPN-6435

Mostly white space changes, see https://github.com/infinispan/infinispan/pull/4179/files?w=1

Looks good to me!

Pulling

Integrated into master branch. Please create another PR for 8.2.x if you'd like.


TypeError:'int' object is not subscriptable during testing

Hi, during testing these is an error arised

TypeError:'int' object is not subscriptable

Some codes of transform.py maybe need to be modified to fix this error. Could you please have a check of this issue?
Thanks a lot in advance.

My setup (for reference)

During the test, the outdoor scene image's size needs to be set to 192x640. As I wrote in the readme, you should set "--loadSize 192 640".

solved, thx :-)


fix(Step): PropType warning for style prop

Fixes proptype warning that shows right now for the style prop on the Step component.

Test fails cause you have other invalid proptypes as well.


Fix unmet dependencies when installing openjdk.

I was testing this PR on openjdk/raspberrypi2/debian/8-jdk/Dockerfile, which was not building before.
With the fix the image builds (even in emulation). However, when used as a base image, the fix creates problems with apt-get, such as:
apt-get install libglib2.0-dev
[...]
The following packages have unmet dependencies:
 libglib2.0-dev : Depends: libglib2.0-0 (= 2.42.1-1+b1) but 2.48.0-1~bpo8+1 is to be installed
                  Depends: libglib2.0-bin (= 2.42.1-1+b1) but it is not going to be installed

apt-get install -t jessie-backports libglib2.0-dev works, but as a base image, this looks cumbersome. Any ideas how to fix this pinning such that apt-get works afterwards as usual?
(As an side note, I was also trying to build the base image without this PR, and without specifying the java version string in apt-get install. It currently builds fine.)

@cskiraly, I see you problem but our base images base on the official base images from Docker (https://github.com/docker-library/openjdk) so we don't want to change the format of the Dockerfile. I think we can pin the jessie-backports repository with smaller priority so that apt will not select package from that repository if we don't specify it. I will update this PR to fix this


Feature request: Add "clear images" to playback

Hi,
I am unable to get the image generation restart when I adjust the timeline (location of the keyframes).  It would be good to have a brute force button to flush the generated images from playback timeline. Of course, if the software recognizes which sections of the timeline are invalid due to keyframe changes and resumes image generation, that would be even better.
Keep up the good work!

Strange, the software does this in my installation, I change a keyframe or I insert one and then the related in-betweens are erased automatically.

I think it sometimes erases the frames on some portions, but many times It does not invalidate them and does nothing.
I also tried to keyframe a diffrent cfg value on whole time duration, but that did not help either

I can't reproduce this. You're welcome reopen with more information like screenshots if it is still an issue.


Fix +grad case in +make-join

This fixes a bug in +make-join where following the +grad arm will cause a build to add itself as a dependency. This adds a test to ensure this doesn't regress.
This also adds several assertion that ensure that a client is not in the list of its sub builds, which were useful in tracking down this bug.
review: @belisarius222
cc: @ixv

LGTM. Note that we also memoized +build-to-tape in this PR.


Default rules

What are the default rules?
When I create a new .eslintrc, the previous rules are overwrited.
I'd like to extend the default plugin rules.

For the default rules please refer to ESLint itself. The extension uses whatever ESLint defines.


Allow roommods and globals to check what rooms a user is banned from

I'd set it so that it's only visible from the more comprehensive level of commands, such as /IP and /alt, but not /whois. Just check for the showAll

I had to remove the auto-rejection of /ip and /alt for non-globals, since it wouldn't be able for non-globals to actually use this command. I tested and didn't find any complications of this.

Out of curiosity, why did you need to remove the rejection of /ip and /alt?

Else you can't use showAll, and it'd show up in a /whois, which you yourself said shouldn't happen.

I think you are misunderstanding me. I meant that the room bans shouldn't show up in /whois. But since room auths need to use it, then my bad, don't put it in showAll.

No, and I agree they shouldn't. I think allowing /whoare to be expanded with things roomauth should know isn't a bad thing in my opinion.

Perhaps this should be roommods and up of only public rooms?

Good point.

Couldn't this potentially leak private rooms to roommods?  (IE - if a user is banned in a private room)

@panpawn A good point, it would require the same checks as for the list a user is in currently.

Hidden and secret rooms are already skipped in the loop.

Ah, alright

There's no reason to skip either at this point; you need to be roomauth in the room to see it anyway, don't you?

Ok.


Channel management on the dispatch portal

Describe the feature
Most servers have radios that use different channels when units are involved in incidents/pursuits etc. Having a column for units radio channel that can be quickly switched in the dispatch portal would allow us to leverage the API to switch their radio channel in game.
Additional Context
No response

Here you need to clarify what kind of voice resource we are talking about.
Someone uses mumble, someone uses pma-voice, there are projects with teamspeak, and someone generally uses the own developed voice resource

Here you need to clarify what kind of voice resource we are talking about. Someone uses mumble, someone uses pma-voice, there are projects with teamspeak, and someone generally uses the own developed voice resource

That's fine as the only thing the CAD will do is represent a channel number. How you integrate that with voice resources is up to you and gives users the flexibility to leverage the API.
For instance, with PMA voice you would just set the channel using the export. For teamspeak I'm not sure maybe theres some TS API you can leverage but frankly thats out of scope of what the CAD can provide. It would just be a value assigned to the unit.

🚀
dispatch:

non-dispatch


change the Vp matrix in FWI code

Hi
I have to create an issue in the change code. Thank you for your guidance
How to change the contents of Vp matrix after several updates?
This sentence causes an error <model.vp.data= some_array>
Regards

vp.data is the Data object and and property so it's immutable, if you want to change it's value you need to add the "indexing" `model.vp.data[:]= some_array``


Failed to verify implicit argument: Subtyping check failed

Update summary: basically F* can't always type-check the types it infers, even if they are correct and everything works well when writing them explicitly.
Some proofs in LambdaOmega.fst are failing when switching to universes with Failed to verify implicit argument: Subtyping check failed error messages like this:
Failed to verify implicit argument: Subtyping check failed; expected type (uu___#3285:LambdaOmega.typ{(Prims.b2t (LambdaOmega.is_TLam uu___@0))}); got type LambdaOmega.typ

The error messages seem at first sight to have little to do with the context where they occur. It's also very hard for me to assess what's really happening, in particular whether F* is now inferring the implicits wrongly or whether it's inferring them correctly, but then for some reason still failing to type check them (it seems that in all cases this is about preconditions of functions applied within the inferred arguments that are reported as failing for no apparent reason). In one case where this problem occurred (let rec substitution) I went into the trouble of figuring out the implicits and passing them explicitly and then everything worked fine, but figuring out all the implicits is very painful in general, so I'm still admitting a proof in LambdaOmega.fst where this problem is pervasive (let rec tred_diamond).
@nikswamy: Any chance to improve this error message so that it shows what F* inferred for the offending implicit? This would help me greatly in better diagnosing such problems.
@nikswamy: Is there any way I can see what F* used to infer for implicits in the --stratified mode so that I don't need to infer that information myself?
In both cases, I've tried --dump_module LambdaOmega --print_implicits, but this doesn't seem to display the implicits in the code it dumps.

This problem seems to have appeared in StlcCbvDbParSubst.fst too, which should explain Nik's commit message for fd55545d ("a couple of more STLC examples ... the main trouble seems to be the more restrictive implicit parameter semantics") and code like this:
val preservation : #e:exp -> #t:typ -> h:typing empty e t{is_Some (step e)} ->
      Tot (typing empty (Some.v (step e)) t) (decreases e)
let rec preservation #e #t h =
  let TyApp #g #e1 #e2 #t11 #t12 h1 h2 = h in
     if is_value e1
     then (if is_value e2
           then let TyLam t_x hbody = h1 in
                (extend_gen_0 t_x empty;
                 substitution_preserves_typing 0 h2 hbody)
           else TyApp #_ #_ #(Some.v (step e2)) #_ #_ h1 (preservation h2))
     else TyApp #_ #(Some.v (step e1)) #_ #_ #_ (preservation h1) h2

I'm going to give this #_ a try, wasn't aware of this syntax.

See point 2 here: https://github.com/FStarLang/FStar/wiki/Migrating-code-to-use-the---universes-mode-(particularly,-as-related-to-mitls-fstar)

There's a improvement I've discussed with @protz of re-checking a term when implicits fail...perhaps it's time to implement it

Not sure if it's correct to tag this a bug. It was recorded from the start as a known design constraint in the universes branch. Enhancement, perhaps?

This is the main blocker for porting the remaining large metatheory examples to universes. The solution we discussed involves a big revamp of the type-checker, splitting it into 2 different passes.

Closing this issue. With two phases, the implicit annotations in LambdaOmega are no longer required.


Add TPCH query 2 to TpchQueryBuilder

Adds TPC-H query 2 to TpchQueryBuilder.
Extends TpchBenchmark and ParquetTpchTest with query 2.
Performance comparison with DuckDb (with Parquet file format):
| # Num Threads/ Drivers | Velox(seconds) | DuckDB(seconds) |
|:----------------------:|:--------------:|:---------------:|
|            1           |      1.03      |       3.41      |
|            4           |      0.84      |       0.98      |
|            8           |      0.95      |       0.63      |
|           16           |      1.01      |       0.80      |

Output of PrintPlanWithStats for 4 drivers:
Execution time: 1.91s
Splits total: 440, finished: 440
-- Project[expressions: (s_acctbal:DOUBLE, ROW["s_acctbal"]), (s_name:VARCHAR, ROW["s_name"]), (n_name:VARCHAR, ROW["n_name"]), (p_partkey:BIGINT, ROW["p_partkey"]), (p_mfgr:VARCHAR, ROW["p_mfgr"]), (s_address:VARCHAR, ROW["s_address"]), (s_phone:VARCHAR, ROW["s_phone"]), (s_comment:VARCHAR, ROW["s_comment"])] -> s_acctbal:DOUBLE, s_name:VARCHAR, n_name:VARCHAR, p_partkey:BIGINT, p_mfgr:VARCHAR, s_address:VARCHAR, s_phone:VARCHAR, s_comment:VARCHAR
   Output: 4667 rows (1.41MB, 1 batches), Cpu time: 58.00us, Blocked wall time: 0ns, Peak memory: 0B, Memory allocations: 0, Threads: 1
  -- OrderBy[s_acctbal DESC NULLS LAST, n_name ASC NULLS LAST, s_name ASC NULLS LAST, p_partkey ASC NULLS LAST] -> s_acctbal:DOUBLE, s_name:VARCHAR, s_address:VARCHAR, s_phone:VARCHAR, s_comment:VARCHAR, ps_supplycost:DOUBLE, p_partkey:BIGINT, p_mfgr:VARCHAR, n_name:VARCHAR, min_supplycost:DOUBLE
     Output: 4667 rows (1.50MB, 1 batches), Cpu time: 20.58ms, Blocked wall time: 0ns, Peak memory: 3.00MB, Memory allocations: 52, Threads: 1
    -- Filter[expression: eq(ROW["ps_supplycost"],ROW["min_supplycost"])] -> s_acctbal:DOUBLE, s_name:VARCHAR, s_address:VARCHAR, s_phone:VARCHAR, s_comment:VARCHAR, ps_supplycost:DOUBLE, p_partkey:BIGINT, p_mfgr:VARCHAR, n_name:VARCHAR, min_supplycost:DOUBLE
       Output: 4667 rows (164.92MB, 799 batches), Cpu time: 17.38ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 5, Threads: 1
      -- HashJoin[LEFT p_partkey=ps_partkey] -> s_acctbal:DOUBLE, s_name:VARCHAR, s_address:VARCHAR, s_phone:VARCHAR, s_comment:VARCHAR, ps_supplycost:DOUBLE, p_partkey:BIGINT, p_mfgr:VARCHAR, n_name:VARCHAR, min_supplycost:DOUBLE
         Output: 6351 rows (217.62MB, 799 batches), Cpu time: 141.19ms, Blocked wall time: 1.17s, Peak memory: 57.00MB, Memory allocations: 1410
         HashBuild: Input: 1183098 rows (27.06MB, 1156 batches), Output: 0 rows (0B, 0 batches), Cpu time: 126.11ms, Blocked wall time: 0ns, Peak memory: 56.00MB, Memory allocations: 598, Threads: 1
            queuedWallNanos    sum: 216.00us, count: 1, min: 216.00us, max: 216.00us
            rangeKey0          sum: 2000000, count: 1, min: 2000000, max: 2000000
         HashProbe: Input: 6351 rows (217.47MB, 799 batches), Output: 6351 rows (217.62MB, 799 batches), Cpu time: 15.08ms, Blocked wall time: 1.17s, Peak memory: 1.00MB, Memory allocations: 812, Threads: 1
            queuedWallNanos    sum: 43.00us, count: 1, min: 43.00us, max: 43.00us
        -- HashJoin[INNER ps_suppkey=s_suppkey] -> s_acctbal:DOUBLE, s_name:VARCHAR, s_address:VARCHAR, s_phone:VARCHAR, s_comment:VARCHAR, ps_supplycost:DOUBLE, p_partkey:BIGINT, p_mfgr:VARCHAR, n_name:VARCHAR
           Output: 6351 rows (217.47MB, 799 batches), Cpu time: 55.91ms, Blocked wall time: 56.15ms, Peak memory: 4.00MB, Memory allocations: 4715
           HashBuild: Input: 20033 rows (6.42MB, 25 batches), Output: 0 rows (0B, 0 batches), Cpu time: 33.73ms, Blocked wall time: 56.15ms, Peak memory: 3.00MB, Memory allocations: 85, Threads: 4
              distinctKey0       sum: 20034, count: 1, min: 20034, max: 20034
              queuedWallNanos    sum: 13.64ms, count: 7, min: 94.00us, max: 4.51ms
              rangeKey0          sum: 99992, count: 1, min: 99992, max: 99992
           HashProbe: Input: 6351 rows (38.17MB, 799 batches), Output: 6351 rows (217.47MB, 799 batches), Cpu time: 22.18ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 4630, Threads: 1
              dynamicFiltersProduced    sum: 1, count: 1, min: 1, max: 1
          -- HashJoin[INNER ps_partkey=p_partkey] -> ps_suppkey:BIGINT, ps_supplycost:DOUBLE, p_partkey:BIGINT, p_mfgr:VARCHAR
             Output: 6351 rows (38.17MB, 799 batches), Cpu time: 50.27ms, Blocked wall time: 39.08ms, Peak memory: 17.00MB, Memory allocations: 827
             HashBuild: Input: 7854 rows (763.69KB, 205 batches), Output: 0 rows (0B, 0 batches), Cpu time: 34.22ms, Blocked wall time: 39.08ms, Peak memory: 16.00MB, Memory allocations: 19, Threads: 4
                distinctKey0       sum: 7855, count: 1, min: 7855, max: 7855
                queuedWallNanos    sum: 4.11ms, count: 7, min: 84.00us, max: 1.26ms
                rangeKey0          sum: 1999507, count: 1, min: 1999507, max: 1999507
             HashProbe: Input: 6351 rows (74.88MB, 799 batches), Output: 6351 rows (38.17MB, 799 batches), Cpu time: 16.05ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 808, Threads: 1
                dynamicFiltersProduced    sum: 1, count: 1, min: 1, max: 1
            -- TableScan[table: partsupp] -> ps_partkey:BIGINT, ps_suppkey:BIGINT, ps_supplycost:DOUBLE
               Input: 6351 rows (74.88MB, 0 batches), Raw Input: 8000000 rows (127.12MB), Output: 6351 rows (74.88MB, 799 batches), Cpu time: 578.58ms, Blocked wall time: 0ns, Peak memory: 11.00MB, Memory allocations: 5018, Threads: 1, Splits: 80
                  dataSourceWallNanos       sum: 563.17ms, count: 884, min: 3.00us, max: 9.82ms
                  dynamicFiltersAccepted    sum: 2, count: 2, min: 1, max: 1
                  localReadBytes            sum: 0B, count: 1, min: 0B, max: 0B
                  numLocalRead              sum: 0, count: 1, min: 0, max: 0
                  numPrefetch               sum: 0, count: 1, min: 0, max: 0
                  numRamRead                sum: 0, count: 1, min: 0, max: 0
                  numStorageRead            sum: 0, count: 1, min: 0, max: 0
                  prefetchBytes             sum: 0B, count: 1, min: 0B, max: 0B
                  ramReadBytes              sum: 0B, count: 1, min: 0B, max: 0B
                  skippedSplitBytes         sum: 0B, count: 1, min: 0B, max: 0B
                  skippedSplits             sum: 0, count: 1, min: 0, max: 0
                  skippedStrides            sum: 0, count: 1, min: 0, max: 0
                  storageReadBytes          sum: 0B, count: 1, min: 0B, max: 0B
            -- Filter[expression: eq(cast ROW["p_size"] as BIGINT,15)] -> p_partkey:BIGINT, p_mfgr:VARCHAR, p_size:INTEGER, p_type:VARCHAR
               Output: 7854 rows (763.69KB, 205 batches), Cpu time: 30.09ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 220, Threads: 4
              -- TableScan[table: part, remaining filter: (like(ROW["type"],"%BRASS"))] -> p_partkey:BIGINT, p_mfgr:VARCHAR, p_size:INTEGER, p_type:VARCHAR
                 Input: 399587 rows (141.74MB, 0 batches), Raw Input: 2000000 rows (426.90MB), Output: 399587 rows (37.96MB, 205 batches), Cpu time: 544.41ms, Blocked wall time: 0ns, Peak memory: 3.00MB, Memory allocations: 2266, Threads: 4, Splits: 80
                    dataSourceWallNanos    sum: 276.72ms, count: 285, min: 8.00us, max: 37.80ms
                    localReadBytes         sum: 0B, count: 4, min: 0B, max: 0B
                    numLocalRead           sum: 0, count: 4, min: 0, max: 0
                    numPrefetch            sum: 0, count: 4, min: 0, max: 0
                    numRamRead             sum: 0, count: 4, min: 0, max: 0
                    numStorageRead         sum: 0, count: 4, min: 0, max: 0
                    prefetchBytes          sum: 0B, count: 4, min: 0B, max: 0B
                    ramReadBytes           sum: 0B, count: 4, min: 0B, max: 0B
                    skippedSplitBytes      sum: 0B, count: 4, min: 0B, max: 0B
                    skippedSplits          sum: 0, count: 4, min: 0, max: 0
                    skippedStrides         sum: 0, count: 4, min: 0, max: 0
                    storageReadBytes       sum: 0B, count: 4, min: 0B, max: 0B
          -- HashJoin[INNER s_nationkey=n_nationkey] -> s_acctbal:DOUBLE, s_name:VARCHAR, s_address:VARCHAR, s_phone:VARCHAR, s_comment:VARCHAR, s_suppkey:BIGINT, n_name:VARCHAR
             Output: 20033 rows (6.42MB, 25 batches), Cpu time: 3.01ms, Blocked wall time: 8.37ms, Peak memory: 2.00MB, Memory allocations: 60
             HashBuild: Input: 5 rows (24.16KB, 1 batches), Output: 0 rows (0B, 0 batches), Cpu time: 482.00us, Blocked wall time: 505.00us, Peak memory: 1.00MB, Memory allocations: 3, Threads: 4
                distinctKey0       sum: 6, count: 1, min: 6, max: 6
                queuedWallNanos    sum: 639.00us, count: 7, min: 24.00us, max: 188.00us
                rangeKey0          sum: 19, count: 1, min: 19, max: 19
             HashProbe: Input: 20033 rows (5.62MB, 13 batches), Output: 20033 rows (6.42MB, 25 batches), Cpu time: 2.53ms, Blocked wall time: 7.87ms, Peak memory: 1.00MB, Memory allocations: 57, Threads: 4
                dynamicFiltersProduced    sum: 4, count: 4, min: 1, max: 1
                queuedWallNanos           sum: 452.00us, count: 4, min: 88.00us, max: 142.00us
            -- TableScan[table: supplier] -> s_nationkey:BIGINT, s_acctbal:DOUBLE, s_address:VARCHAR, s_comment:VARCHAR, s_name:VARCHAR, s_phone:VARCHAR, s_suppkey:BIGINT
               Input: 20033 rows (5.62MB, 0 batches), Raw Input: 100000 rows (54.35MB), Output: 20033 rows (5.62MB, 13 batches), Cpu time: 115.27ms, Blocked wall time: 0ns, Peak memory: 5.00MB, Memory allocations: 526, Threads: 4, Splits: 80
                  dataSourceWallNanos       sum: 132.42ms, count: 93, min: 6.00us, max: 25.33ms
                  dynamicFiltersAccepted    sum: 4, count: 4, min: 1, max: 1
                  localReadBytes            sum: 0B, count: 4, min: 0B, max: 0B
                  numLocalRead              sum: 0, count: 4, min: 0, max: 0
                  numPrefetch               sum: 0, count: 4, min: 0, max: 0
                  numRamRead                sum: 0, count: 4, min: 0, max: 0
                  numStorageRead            sum: 0, count: 4, min: 0, max: 0
                  prefetchBytes             sum: 0B, count: 4, min: 0B, max: 0B
                  ramReadBytes              sum: 0B, count: 4, min: 0B, max: 0B
                  skippedSplitBytes         sum: 0B, count: 4, min: 0B, max: 0B
                  skippedSplits             sum: 0, count: 4, min: 0, max: 0
                  skippedStrides            sum: 0, count: 4, min: 0, max: 0
                  storageReadBytes          sum: 0B, count: 4, min: 0B, max: 0B
            -- HashJoin[INNER n_regionkey=r_regionkey] -> n_nationkey:BIGINT, n_name:VARCHAR
               Output: 5 rows (24.16KB, 1 batches), Cpu time: 542.00us, Blocked wall time: 4.64ms, Peak memory: 1.00MB, Memory allocations: 2
               HashBuild: Input: 1 rows (256B, 1 batches), Output: 0 rows (0B, 0 batches), Cpu time: 445.00us, Blocked wall time: 726.00us, Peak memory: 1.00MB, Memory allocations: 2, Threads: 4
                  distinctKey0       sum: 2, count: 1, min: 2, max: 2
                  queuedWallNanos    sum: 856.00us, count: 7, min: 16.00us, max: 212.00us
                  rangeKey0          sum: 2, count: 1, min: 2, max: 2
               HashProbe: Input: 5 rows (24.44KB, 1 batches), Output: 5 rows (24.16KB, 1 batches), Cpu time: 97.00us, Blocked wall time: 3.92ms, Peak memory: 0B, Memory allocations: 0, Threads: 4
                  dynamicFiltersProduced           sum: 4, count: 4, min: 1, max: 1
                  queuedWallNanos                  sum: 431.00us, count: 4, min: 79.00us, max: 163.00us
                  replacedWithDynamicFilterRows    sum: 5, count: 1, min: 5, max: 5
              -- TableScan[table: nation] -> n_nationkey:BIGINT, n_name:VARCHAR, n_regionkey:BIGINT
                 Input: 5 rows (24.44KB, 0 batches), Raw Input: 25 rows (21.80KB), Output: 5 rows (24.44KB, 1 batches), Cpu time: 1.14ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 35, Threads: 4, Splits: 10
                    dataSourceWallNanos       sum: 186.00us, count: 11, min: 5.00us, max: 90.00us
                    dynamicFiltersAccepted    sum: 4, count: 4, min: 1, max: 1
                    localReadBytes            sum: 0B, count: 4, min: 0B, max: 0B
                    numLocalRead              sum: 0, count: 4, min: 0, max: 0
                    numPrefetch               sum: 0, count: 4, min: 0, max: 0
                    numRamRead                sum: 0, count: 4, min: 0, max: 0
                    numStorageRead            sum: 0, count: 4, min: 0, max: 0
                    prefetchBytes             sum: 0B, count: 4, min: 0B, max: 0B
                    ramReadBytes              sum: 0B, count: 4, min: 0B, max: 0B
                    skippedSplitBytes         sum: 0B, count: 4, min: 0B, max: 0B
                    skippedSplits             sum: 0, count: 4, min: 0, max: 0
                    skippedStrides            sum: 0, count: 4, min: 0, max: 0
                    storageReadBytes          sum: 0B, count: 4, min: 0B, max: 0B
              -- TableScan[table: region, range filters: [(name, Filter(BytesValues, deterministic, null not allowed))]] -> r_regionkey:BIGINT, r_name:VARCHAR
                 Input: 1 rows (256B, 0 batches), Raw Input: 5 rows (11.49KB), Output: 1 rows (256B, 1 batches), Cpu time: 1.74ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 28, Threads: 4, Splits: 10
                    dataSourceWallNanos    sum: 429.00us, count: 11, min: 5.00us, max: 223.00us
                    localReadBytes         sum: 0B, count: 4, min: 0B, max: 0B
                    numLocalRead           sum: 0, count: 4, min: 0, max: 0
                    numPrefetch            sum: 0, count: 4, min: 0, max: 0
                    numRamRead             sum: 0, count: 4, min: 0, max: 0
                    numStorageRead         sum: 0, count: 4, min: 0, max: 0
                    prefetchBytes          sum: 0B, count: 4, min: 0B, max: 0B
                    ramReadBytes           sum: 0B, count: 4, min: 0B, max: 0B
                    skippedSplitBytes      sum: 0B, count: 4, min: 0B, max: 0B
                    skippedSplits          sum: 0, count: 4, min: 0, max: 0
                    skippedStrides         sum: 0, count: 4, min: 0, max: 0
                    storageReadBytes       sum: 0B, count: 4, min: 0B, max: 0B
        -- Aggregation[FINAL [ps_partkey] min_supplycost := min("min_supplycost")] -> ps_partkey:BIGINT, min_supplycost:DOUBLE
           Output: 1183098 rows (27.06MB, 1156 batches), Cpu time: 416.49ms, Blocked wall time: 0ns, Peak memory: 48.00MB, Memory allocations: 1621, Threads: 1
          -- LocalPartition[GATHER] -> ps_partkey:BIGINT, min_supplycost:DOUBLE
             Output: 2366464 rows (59.01MB, 1261 batches), Cpu time: 29.85ms, Blocked wall time: 1.31s, Peak memory: 0B, Memory allocations: 0
             LocalPartition: Input: 1183232 rows (29.50MB, 1261 batches), Output: 1183232 rows (29.50MB, 0 batches), Cpu time: 21.16ms, Blocked wall time: 871.56ms, Peak memory: 0B, Memory allocations: 0, Threads: 4
                queuedWallNanos    sum: 1.09ms, count: 8, min: 21.00us, max: 266.00us
             LocalExchange: Input: 1183232 rows (29.50MB, 0 batches), Output: 1183232 rows (29.50MB, 1261 batches), Cpu time: 8.68ms, Blocked wall time: 442.78ms, Peak memory: 0B, Memory allocations: 0, Threads: 1
                queuedWallNanos    sum: 94.64ms, count: 129, min: 38.00us, max: 4.52ms
            -- Aggregation[PARTIAL [ps_partkey] min_supplycost := min(ROW["ps_supplycost"])] -> ps_partkey:BIGINT, min_supplycost:DOUBLE
               Output: 1183232 rows (29.50MB, 1261 batches), Cpu time: 1.30s, Blocked wall time: 0ns, Peak memory: 32.00MB, Memory allocations: 4353, Threads: 4
                  flushRowCount            sum: 734805, count: 189, min: 122, max: 458569
                  partialAggregationPct    sum: 13860, count: 189, min: 71, max: 75
              -- HashJoin[INNER ps_suppkey=s_suppkey] -> ps_supplycost:DOUBLE, ps_partkey:BIGINT
                 Output: 1602640 rows (27.63MB, 804 batches), Cpu time: 22.24ms, Blocked wall time: 169.74ms, Peak memory: 1.00MB, Memory allocations: 10
                 HashBuild: Input: 20033 rows (180.78KB, 13 batches), Output: 0 rows (0B, 0 batches), Cpu time: 5.44ms, Blocked wall time: 1.87ms, Peak memory: 1.00MB, Memory allocations: 10, Threads: 4
                    distinctKey0       sum: 20034, count: 1, min: 20034, max: 20034
                    queuedWallNanos    sum: 16.01ms, count: 7, min: 265.00us, max: 5.08ms
                    rangeKey0          sum: 99992, count: 1, min: 99992, max: 99992
                 HashProbe: Input: 1602640 rows (102.51MB, 804 batches), Output: 1602640 rows (27.63MB, 804 batches), Cpu time: 16.80ms, Blocked wall time: 167.87ms, Peak memory: 0B, Memory allocations: 0, Threads: 4
                    dynamicFiltersProduced           sum: 4, count: 4, min: 1, max: 1
                    queuedWallNanos                  sum: 2.12ms, count: 4, min: 141.00us, max: 736.00us
                    replacedWithDynamicFilterRows    sum: 1602640, count: 804, min: 163, max: 2111
                -- TableScan[table: partsupp] -> ps_partkey:BIGINT, ps_suppkey:BIGINT, ps_supplycost:DOUBLE
                   Input: 1602640 rows (102.51MB, 0 batches), Raw Input: 8000000 rows (127.12MB), Output: 1602640 rows (102.51MB, 804 batches), Cpu time: 923.59ms, Blocked wall time: 0ns, Peak memory: 11.00MB, Memory allocations: 4991, Threads: 4, Splits: 80
                      dataSourceWallNanos       sum: 1.06s, count: 884, min: 5.00us, max: 18.66ms
                      dynamicFiltersAccepted    sum: 4, count: 4, min: 1, max: 1
                      localReadBytes            sum: 0B, count: 4, min: 0B, max: 0B
                      numLocalRead              sum: 0, count: 4, min: 0, max: 0
                      numPrefetch               sum: 0, count: 4, min: 0, max: 0
                      numRamRead                sum: 0, count: 4, min: 0, max: 0
                      numStorageRead            sum: 0, count: 4, min: 0, max: 0
                      prefetchBytes             sum: 0B, count: 4, min: 0B, max: 0B
                      ramReadBytes              sum: 0B, count: 4, min: 0B, max: 0B
                      skippedSplitBytes         sum: 0B, count: 4, min: 0B, max: 0B
                      skippedSplits             sum: 0, count: 4, min: 0, max: 0
                      skippedStrides            sum: 0, count: 4, min: 0, max: 0
                      storageReadBytes          sum: 0B, count: 4, min: 0B, max: 0B
                -- HashJoin[INNER s_nationkey=n_nationkey] -> s_suppkey:BIGINT
                   Output: 20033 rows (180.78KB, 13 batches), Cpu time: 685.00us, Blocked wall time: 6.98ms, Peak memory: 1.00MB, Memory allocations: 2
                   HashBuild: Input: 5 rows (96B, 1 batches), Output: 0 rows (0B, 0 batches), Cpu time: 346.00us, Blocked wall time: 277.00us, Peak memory: 1.00MB, Memory allocations: 2, Threads: 4
                      distinctKey0       sum: 6, count: 1, min: 6, max: 6
                      queuedWallNanos    sum: 1.34ms, count: 7, min: 24.00us, max: 316.00us
                      rangeKey0          sum: 19, count: 1, min: 19, max: 19
                   HashProbe: Input: 20033 rows (1.13MB, 13 batches), Output: 20033 rows (180.78KB, 13 batches), Cpu time: 339.00us, Blocked wall time: 6.71ms, Peak memory: 0B, Memory allocations: 0, Threads: 4
                      dynamicFiltersProduced           sum: 4, count: 4, min: 1, max: 1
                      queuedWallNanos                  sum: 257.00us, count: 4, min: 18.00us, max: 179.00us
                      replacedWithDynamicFilterRows    sum: 20033, count: 13, min: 489, max: 2058
                  -- TableScan[table: supplier] -> s_suppkey:BIGINT, s_nationkey:BIGINT
                     Input: 20033 rows (1.13MB, 0 batches), Raw Input: 100000 rows (51.89MB), Output: 20033 rows (1.13MB, 13 batches), Cpu time: 46.06ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 192, Threads: 4, Splits: 80
                        dataSourceWallNanos       sum: 17.46ms, count: 93, min: 5.00us, max: 6.32ms
                        dynamicFiltersAccepted    sum: 4, count: 4, min: 1, max: 1
                        localReadBytes            sum: 0B, count: 4, min: 0B, max: 0B
                        numLocalRead              sum: 0, count: 4, min: 0, max: 0
                        numPrefetch               sum: 0, count: 4, min: 0, max: 0
                        numRamRead                sum: 0, count: 4, min: 0, max: 0
                        numStorageRead            sum: 0, count: 4, min: 0, max: 0
                        prefetchBytes             sum: 0B, count: 4, min: 0B, max: 0B
                        ramReadBytes              sum: 0B, count: 4, min: 0B, max: 0B
                        skippedSplitBytes         sum: 0B, count: 4, min: 0B, max: 0B
                        skippedSplits             sum: 0, count: 4, min: 0, max: 0
                        skippedStrides            sum: 0, count: 4, min: 0, max: 0
                        storageReadBytes          sum: 0B, count: 4, min: 0B, max: 0B
                  -- HashJoin[INNER n_regionkey=r_regionkey] -> n_nationkey:BIGINT
                     Output: 5 rows (96B, 1 batches), Cpu time: 555.00us, Blocked wall time: 4.28ms, Peak memory: 1.00MB, Memory allocations: 2
                     HashBuild: Input: 1 rows (256B, 1 batches), Output: 0 rows (0B, 0 batches), Cpu time: 452.00us, Blocked wall time: 866.00us, Peak memory: 1.00MB, Memory allocations: 2, Threads: 4
                        distinctKey0       sum: 2, count: 1, min: 2, max: 2
                        queuedWallNanos    sum: 1.39ms, count: 7, min: 16.00us, max: 356.00us
                        rangeKey0          sum: 2, count: 1, min: 2, max: 2
                     HashProbe: Input: 5 rows (384B, 1 batches), Output: 5 rows (96B, 1 batches), Cpu time: 103.00us, Blocked wall time: 3.41ms, Peak memory: 0B, Memory allocations: 0, Threads: 4
                        dynamicFiltersProduced           sum: 4, count: 4, min: 1, max: 1
                        queuedWallNanos                  sum: 559.00us, count: 4, min: 98.00us, max: 163.00us
                        replacedWithDynamicFilterRows    sum: 5, count: 1, min: 5, max: 5
                    -- TableScan[table: nation] -> n_nationkey:BIGINT, n_regionkey:BIGINT
                       Input: 5 rows (384B, 0 batches), Raw Input: 25 rows (21.80KB), Output: 5 rows (384B, 1 batches), Cpu time: 1.04ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 27, Threads: 4, Splits: 10
                          dataSourceWallNanos       sum: 182.00us, count: 11, min: 5.00us, max: 99.00us
                          dynamicFiltersAccepted    sum: 4, count: 4, min: 1, max: 1
                          localReadBytes            sum: 0B, count: 4, min: 0B, max: 0B
                          numLocalRead              sum: 0, count: 4, min: 0, max: 0
                          numPrefetch               sum: 0, count: 4, min: 0, max: 0
                          numRamRead                sum: 0, count: 4, min: 0, max: 0
                          numStorageRead            sum: 0, count: 4, min: 0, max: 0
                          prefetchBytes             sum: 0B, count: 4, min: 0B, max: 0B
                          ramReadBytes              sum: 0B, count: 4, min: 0B, max: 0B
                          skippedSplitBytes         sum: 0B, count: 4, min: 0B, max: 0B
                          skippedSplits             sum: 0, count: 4, min: 0, max: 0
                          skippedStrides            sum: 0, count: 4, min: 0, max: 0
                          storageReadBytes          sum: 0B, count: 4, min: 0B, max: 0B
                    -- TableScan[table: region, range filters: [(name, Filter(BytesValues, deterministic, null not allowed))]] -> r_regionkey:BIGINT, r_name:VARCHAR
                       Input: 1 rows (256B, 0 batches), Raw Input: 5 rows (11.49KB), Output: 1 rows (256B, 1 batches), Cpu time: 1.42ms, Blocked wall time: 0ns, Peak memory: 1.00MB, Memory allocations: 28, Threads: 4, Splits: 10
                          dataSourceWallNanos    sum: 440.00us, count: 11, min: 5.00us, max: 223.00us
                          localReadBytes         sum: 0B, count: 4, min: 0B, max: 0B
                          numLocalRead           sum: 0, count: 4, min: 0, max: 0
                          numPrefetch            sum: 0, count: 4, min: 0, max: 0
                          numRamRead             sum: 0, count: 4, min: 0, max: 0
                          numStorageRead         sum: 0, count: 4, min: 0, max: 0
                          prefetchBytes          sum: 0B, count: 4, min: 0B, max: 0B
                          ramReadBytes           sum: 0B, count: 4, min: 0B, max: 0B
                          skippedSplitBytes      sum: 0B, count: 4, min: 0B, max: 0B
                          skippedSplits          sum: 0, count: 4, min: 0, max: 0
                          skippedStrides         sum: 0, count: 4, min: 0, max: 0
                          storageReadBytes       sum: 0B, count: 4, min: 0B, max: 0B

Resolved by https://github.com/facebookincubator/velox/pull/9825 .


Simplify code

I'm a fond user of xoroshiro myself and a C++ programmer. Thank you for this great work!
There is a lot of common, redundant code between the simulators generators. Have you ever considered writing a generic, templated master class and then defining individual RNGs as parameterizations of it?
using XoroShrio256PlusPlus = XoroShiro<256, 64, variant::pp>;

Would be happy to do the refactoring if you think it's worthwhile..

I think making generator classes templatized could bring unnecessary complexity for maintainers and misuse of API.
Instead of templatization, identical jump functions can call a common function to remove redundant code. It will reduce LoC by 10～20%. I will try this in the next update.


pattern match apps by name

When you select apps and it finds multiple you should be able to say all, so for example.
select "adobe" returns 17 results, if I could say "all" in the next prompt it would make pattern matching work better.
that way I can set all my adobe apps to use egpu easily.

Sorry haven’t had time to work on this. Will incorporate in a future release if I come up with some more refinements.


feat: cortex start

Goal

We should have a clear start command, which takes port number
This should differentiate from cortex, which should be more similar to -h and also show where data is persisted

Clarifications needed

Is cortex start a pre-requisite to cortex run?
cortex run should automatically start a server if it is not already running

Tasklist

[x] #1234

Is cortex start a pre-requisite to cortex run?

Yes, it is
cortex run should automatically start a server if it is not already running

We don't start server automatically yet, will add it soon
@dan-homebrew I think this change is reasonable. Let me take a stab at it. However
This should differentiate from cortex, which should be more similar to -h and also show where data is persisted

this change may take time, so will work on cortex start first

Is cortex start a pre-requisite to cortex run?

Yes, it is
cortex run should automatically start a server if it is not already running

We don't start server automatically yet, will add it soon
@dan-homebrew I think cortex start change is reasonable. Let me take a stab at it. However
This should differentiate from cortex, which should be more similar to -h and also show where data is persisted

this change may take time, so will work on cortex start first

Got it, thank you @vansangpfiev

Resolved by https://github.com/janhq/cortex.cpp/issues/1234


[Feature] Timer System WIP

Description
This adds an easy-to-use Timer system to Fungus
Why would Fungus need this?
It's pretty common to set time limits in games or check how long things took. It's even more common to track the player's playtime, yet as all official releases of Fungus (at the time of this writing) lack that, that forces devs to look to other things to implement those features.
With this, we save devs the trouble. Plus, the new save system really needs this one; it has to be able to show playtime in the UI, after all. Heck, that's the reason I even went through all this effort xD
Important Notes

My change requires modifications or additions to documentation
My change modifies FungusManager

I needed a way to make sure that the TimerManager is in all scenes, and as I want this to be a built-in feature...

My change adds unit tests
My change adds demos to FungusExamples

In the TimerSystem folder

I have a tutorial right here: https://docs.google.com/document/d/1o5XB6SLRMc5HJ2v9lCYS_SCkeoGBLEnISQ7BRp9WIHw/edit?usp=sharing

Other information
While I think the system is production-ready as-is, I would very much like to get feedback on it before it gets approved for an official release.

I think things are looking pretty good now ^^ Thoughts, @chrisgregan and @stevehalliwell ?


[FEATURE] CONCAT on more than two strings

Is your feature request related to a problem?
curl --location --request POST 'http://localhost:9200/_plugins/_sql' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--data-raw '{
    "query": "SELECT concat(\"hello \", \"world\", \"!\") FROM calcs"
}'

returns:
{
  "error": {
    "reason": "Invalid SQL query",
    "details": "concat function expected {[STRING,STRING]}, but get [STRING,STRING,STRING]",
    "type": "ExpressionEvaluationException"
  },
  "status": 400
}

What solution would you like?
Expect the concatenated result:  hello world!
What alternatives have you considered?
Nested queries do work, such as:
{
    "query": "SELECT concat(concat(\"abc\", \"def\"), \"ghi\");"
}

returns:
"abcdefghi"

Do you have any additional context?
n/a

This may need varargs support or array type which are missing now.

At least we can add concat signatures which accept up to 5-8 args and update doc. A user who wants more can use nested call: concat(concat(1, 2, 3, 4), 5, 6, 7, 8)

PR: https://github.com/opensearch-project/sql/pull/1279


move getFeatureFlagsBaseOnAPIFlag from custom_task_test to another file

The getFeatureFlagsBaseOnAPIFlag is used in multiple tests, and when developers want to introduce a new feature flag, they need to change this functions as well.
It's not clear since the helper function is in custom_task_test and also cause confusions to reviewers. We should move it to another file

If this issue is still open then please assign me

If this issue is still open then please assign me

Thanks!


Proofs of Partial Knowledge

Implements proofs of partial knowledge

Missing: documentation

Thanks for the helpful review, @this-kramer :)

So it seems this included a backwards-incompatible API change? In that case the major version number needs to be incremented.

In that case, we'd never release a 2.0.0, only 3.0.0.
I thought I could piggyback onto the 2.0.0 version, which is unreleased right now. So in my mind, it's still "under development" and can be loaded with additional API-breaking changes.

Wait, isnt the newest Craco version increment 1.1.0? Math is at 2.0.0. I agree with the "piggybacking" though.

My bad. You're right 👍


Rick Espinoza Develop

Hi Clara!
The contact html was going to be a stretch a goal, but it never got done :( I ran out of time. Thanks for the feedback!!
Rick

On Aug 1, 2018, at 7:22 PM, Clara<EMAIL_ADDRESS>wrote:
@clarakosi commented on this pull request.
Github FU
Multiple commits with meaningful messages
Pull request with name in Title
Pull request from master branch
Requested Improvements
Great job overall 👍 . I would recommend focusing on small details like the bottom navigation and making sure it is also linked.
Questions
I noticed you had an html file linked that you didn't use. Was this for a personal stretch goal?
Rating: {1-3}
2 - I checked your page and noticed you've already merged this branch to master so great job Rick! 💯
In about.html:

Great naming scheme!
In about.html:

Leverage agile frameworks to provide a robust synopsis for high level overviews. Iterative approaches to corporate strategy foster collaborative thinking to further the overall value proposition. Organically grow the holistic world view of disruptive innovation via workplace diversity and empowerment.

           Home

           About

           Products

           Blog

           Contact

Where is this contact.html file?
In index.html:

@@ -13,8 +13,19 @@

-
+
+
+
+
+                        Home
Great job linking the files in the header. Consider linking them in the footer as well.
In css/index.css:

+header nav {
Great job using percentages and going a step further by nesting your css. 👍
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


home page fabulousness

✨ 👌 🎨

reworked and styled the homepage a bit
moved to using live-server for the auto css refresh
bumped imagemin-newer to 1.0.2
added card-wide (landscape card)
changed the card implementation
added an icon-ui-yellow class for favorites
fixed all the card images so they show up now

@nikolaswise ^^

no workin' on sunday!


Improve CI

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@709672d). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #62   +/-   ##
=========================================
  Coverage          ?   98.25%
=========================================
  Files             ?        1
  Lines             ?     1146
  Branches          ?        0
=========================================
  Hits              ?     1126
  Misses            ?       20
  Partials          ?        0

Continue to review full report at Codecov.

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

This was more of a learning exercise than a practical PR that I expected to be merged.


Fixes #326, Fixes #593: AdminsController finishing

This PR finishes the AdminsController namespace (Started in #493)
Completed so far (in this PR):

[x] BarcodeItem CRUD
[x] CanonicalItems CRUD
[x] Admin Dashboard
[x] Users CRUD
[x] Organizations CRUD

Most still need specs.

Fixes #593
With the newest updates. I finished the majority of the additional features required for that Issue.
There  may be additional CRUD to add to Admin namespace, will need to check.

I just made some comments on a few things I think were mistakes from copy pasta and a suggestion. (That I'm also happy to implement.)

@seanmarcia @armahillo The "active users" won't work the way you think unless we implement :timeoutable. The db is updated when they sign in, but not while they remain signed in. After being active and signed in for 10 days, they'll fall off the list.

@armahillo I just added to your PR. I put in the @active_users to the dashboard that looks for people logged in in the past week and then displays their name, email, organization, and last login time. I took JC's suggestion and added :timeoutable to the devise configurations on the user model and in the devise initializer I set the timeout time to 600 minutes.

@seanmarcia @armahillo I implemented last_request_at and it updates at most every 10 minutes while a user is active. I upped timeoutable to 7 days instead of 10 hours so we're not logging out the users overnight every day.


Add a Version Check for the Server/CLI

Closes #320
Code Changes

[x] Add an endpoint to the server that returns the version of fidesctl that is running
[x] Add a call in the fidesctl CLI that compares versions with the server

Steps to Confirm

[x] unreachable webserver prints an error and exist
[x] mismatched versions prints a warning and exits

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
[ ] Documentation Updated
[x] Issue Requirements are Met
[x] Relevant Follow-Up Issues Created

Description Of Changes
This does 2 things:

All API commands will now have a health check and a version check run before they are executed. Now if a command fails due to server issues, it should be much more apparent to the end-user than them having to know that fidesctl ping exists and to use it
There is now a version check endpoint in the API. The CLI will hit this endpoint and compare versions. If there is a version discrepancy it will let the user know.

Output
When the health check fails (throws an exception)
(base) PS C:\Users\tal10\Documents\Git\fides\fidesctl> fidesctl ls dataset
Connection failed, webserver is unreachable.
HTTPConnectionPool(host='fidesctl', port=8080): Max retries exceeded with url: /health (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x0000017CFDBB0790>: Failed to establish a
new connection: [Errno 11001] getaddrinfo failed'))

When the versions are mismatched (no exception is raised, just a warning)
root@552be8ba246c:/fides/fidesctl# fidesctl ls dataset
Mismatched versions!
Server Version: 1.4.2+17.g360cd9e.dirty
CLI Version: 1.3.0
[]

@conceptualshark can you help me go through the documentation and get rid of everywhere that ping is mentioned, now that it is done automatically on calls to the API?


Remove link to css file after inlining styles

Fixes https://github.com/zurb/foundation-emails/issues/544 if you agree that the css file is not needed anymore

Let me know if I should do the same change in the 10-minute-responsive-email repository as well.

Rather than removing it as you did, I'd rather use removeLinkTags: true in the inliner function. This is doing exactly what you are aiming for:
.pipe($.inlineCss, {
applyStyleTags: false,
removeStyleTags: false,
applyLinkTags: true,
removeLinkTags: true
})
instead of
.pipe($.inlineCss, {
applyStyleTags: false,
removeStyleTags: false,
applyLinkTags: true
})

Looks good! Thanks!

Thank for the pointer @leschirmeur ! I created pull request #31 to apply your cleaner solution.


bundle exec rake db:create fails - cannot connect through default socket

When I run bundle exec rake db:create I get an error message saying MySQL Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)>
When I navigate to /var/run there is no mysqld directory, which may be the root of the problem. I successfully ran bundle on my locally cloned directory, so the mysql2 gem should have installed correctly.
I'm on Ubuntu 14.04 and believe I used sudo apt-get install libmysqlclient-dev command. I was following the Novice install guide up to this point. Most posts on SO about this issue involve troubleshooting a yml file, but I don't see one in the project. Full error message with trace is below:
dylan@devmachina:~/ruby/huginn$ bundle exec rake db:create --trace
** Invoke db:create (first_time)
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:create
#<Mysql2::Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)>
Couldn't create database for {"adapter"=>"mysql2", "encoding"=>"utf8", "reconnect"=>true, "database"=>"huginn_development", "pool"=>10, "username"=>"root", "password"=>nil, "host"=>nil, "port"=>nil, "socket"=>nil, "strict"=>false}, {:charset=>"utf8", :collation=>"utf8_unicode_ci"}
(If you set the charset manually, make sure you have a matching collation)
#<Mysql2::Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)>
Couldn't create database for {"adapter"=>"mysql2", "encoding"=>"utf8", "reconnect"=>true, "database"=>"huginn_test", "pool"=>10, "username"=>"root", "password"=>nil, "socket"=>nil, "port"=>nil, "strict"=>false}, {:charset=>"utf8", :collation=>"utf8_unicode_ci"}
(If you set the charset manually, make sure you have a matching collation)
rake aborted!
Mysql2::Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/mysql2-0.3.20/lib/mysql2/client.rb:70:in `connect'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/mysql2-0.3.20/lib/mysql2/client.rb:70:in `initialize'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/mysql2_adapter.rb:18:in `new'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/mysql2_adapter.rb:18:in `mysql2_connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:438:in `new_connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:448:in `checkout_new_connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:422:in `acquire_connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:349:in `block in checkout'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:348:in `checkout'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:263:in `block in connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:262:in `connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:571:in `retrieve_connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_handling.rb:113:in `retrieve_connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_handling.rb:87:in `connection'
/home/dylan/ruby/huginn/lib/ar_mysql_column_charset.rb:7:in `block in establish_connection'
/home/dylan/ruby/huginn/lib/ar_mysql_column_charset.rb:6:in `tap'
/home/dylan/ruby/huginn/lib/ar_mysql_column_charset.rb:6:in `establish_connection'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/tasks/database_tasks.rb:109:in `create_current'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/railties/databases.rake:17:in `block (2 levels) in <top (required)>'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/task.rb:240:in `call'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/task.rb:240:in `block in execute'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `each'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `execute'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/task.rb:179:in `block in invoke_with_call_chain'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/2.2.0/monitor.rb:211:in `mon_synchronize'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/task.rb:172:in `invoke_with_call_chain'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/task.rb:165:in `invoke'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:150:in `invoke_task'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block (2 levels) in top_level'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `each'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block in top_level'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:115:in `run_with_threads'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:100:in `top_level'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:78:in `block in run'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:176:in `standard_exception_handling'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/lib/rake/application.rb:75:in `run'
/home/dylan/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/rake-10.5.0/bin/rake:33:in `<top (required)>'
/home/dylan/.rbenv/versions/2.2.4/bin/rake:23:in `load'
/home/dylan/.rbenv/versions/2.2.4/bin/rake:23:in `<main>'

Hi @dylankb,
I recommend you have a look at the manual installation guide it will guide you through all the steps needed to get Huginn up and running.

Woops, missed the step where I actually installed MySQL :S


Enable add sql binding quickpick

Reverting this PR: https://github.com/microsoft/azuredatastudio/pull/17340 with two new changes:

added (preview) to command title
added resourceExtname to when clause to hide the command for untitled files and fixes https://github.com/microsoft/azuredatastudio/issues/17571

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
27232

Relevant Lines:
59274

💛  - Coveralls

Let's also bump the version too so we're ready for the release (0.15.0)


ips is not iterable issue

I following at TracingModule.forRoot at module.ts but when I call API it's throw error like this
TypeError: ips is not iterable
at TracingInterceptor.intercept (.../node_modules/@dollarsign/nestjs-jaeger-tracing/dist/interceptors/tracing.interceptor.js:75:69)
at .../node_modules/@nestjs/core/interceptors/interceptors-consumer.js:23:36
at InterceptorsConsumer.intercept (...node_modules/@nestjs/core/interceptors/interceptors-consumer.js:25:24)
at .../node_modules/@nestjs/core/router/router-execution-context.js:46:60
at Object. (.../node_modules/@nestjs/core/router/router-proxy.js:9:23)
at preHandlerCallback (.../node_modules/fastify/lib/handleRequest.js:124:28)
at preValidationCallback (.../node_modules/fastify/lib/handleRequest.js:107:5)
at handler (.../node_modules/fastify/lib/handleRequest.js:70:7)
at handleRequest (.../node_modules/fastify/lib/handleRequest.js:18:5)
at runPreParsing (.../node_modules/fastify/lib/route.js:391:5)

can you provide us a sample or minimal reproduction


Add hydro styles to ingest

There should be six styles

historical august runoff
projected august runoff
historical evap may
projected evap may
historical soil moisture june
projected soil moisture june

Closing as a less informative duplicate of #70


Ebbw Fawr Learning Community

State funded 3-16 all-through school based in Wales, United Kingdom.
https://www.ebbwfawr.co.uk

@DafyddShort Pull request merged. Thank you!


Improper search indexing

It seems the indexing is done wrong. An example search query result is,
{
    "time": 219,
    "results": [
        {
            "_index": "qtube",
            "_type": "video",
            "_id": "4",
            "_score": 0.56977004,
            "_source": {
                "description": "Description",
                "title": "Title",
                "username": "yrahul",
                "thumbnail": {
                    "size": 482680,
                    "path": "/tmp/upload_1087f1cf95acb80f5de31062ee000b65",
                    "name": "Scan_20160913.png",
                    "type": "image/png",
                    "mtime": "2017-11-04T12:13:58.672Z"
                }
            }
        }
    ]
}

Those details of the thumbnail shouldn't be indexed at all, in fact, we don't have a lot of those details explicitly. Ensure that these values are indexed correctly. I've verified that the DB has the right values stored (but only relative paths are being stored, fix that).
The SearchResults component will depend on this issue. The server.js and search.js files should be looked at as well.

On second thought, I don't know if relative paths in the DB is an issue. The DB will be called from the server path anyway, so the relative paths should work as well.
The indexing needs to be fixed immediately. thumbnail should be a string with the path.

Since this is an indexing issue, I'm assigning you @Rakshitvahi


add ghr deployment in order to upload artifacts to GitHub release page.

Add ghr (https://github.com/tcnksm/ghr) to upload artifacts to GitHub Release page.
This is invoked only a commit to the master.

@shirou LGTM


Using Decay in an optimizer brings up TF warning regarding deprecation of *=

There is a *= used in calculation of effective LR in the epoch, that makes TF complain.

Hello.
Nice point out but, tenfsorflow and keras are updating quite fast.
However, it takes 3-6 months to remove something completely. In your case, you have a warning for something tensorflow will deprecate. There is no problem with your algorithm (I assume) and most probably, keras will be updated before the variable *= will be completely removed from tensorflow.
Please close the issue by pressing the close button under the reply/comment box.

Closing issue since its resolved with the latest version of TensorFlow. Feel free to reopen if the problem still persists. Thanks!


[BUG] executor crash intermittantly in scala2.13-built spark332 integration tests

Describe the bug
After set up regular integrations tests CI for scala2.13-built plugin (built with default jdk8, run with java 17 runtime)
we found intermittent failures of executor crashed no clear reasons in spark 332 IT (spark340 passed fine)

3 runs failed with different test cases
from the executor logs, they showed nothing about why it got killed
from the pod level memory dashboard, the memory footprint is OK (peak ~37GB and the limitation is 60GB)
All 3 failed cases were on different hosts

FAILED ../../src/main/python/window_function_test.py::test_decimal_running_sum_window[Decimal(12,2)][INJECT_OOM, IGNORE_ORDER] - py4j.protocol.Py4JJavaError: An error occurred while calling o1350645.collectToPython.
[2023-11-04T12:55:43.678Z] : org.apache.spark.SparkException: Job aborted due to stage failure: Task 2 in stage 24613.0 failed 1 times, most recent failure: Lost task 2.0 in stage 24613.0 (TID 172988) (<IP_ADDRESS> executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Executor heartbeat timed out after 163377 ms

FAILED ../../src/main/python/delta_lake_merge_test.py::test_delta_merge_match_delete_only[10-['a', 'b']-True-(range(0, 10), range(0, 20))][INJECT_OOM, IGNORE_ORDER, ALLOW_NON_GPU(DeserializeToObjectExec,ShuffleExchangeExec,FileSourceScanExec,FilterExec,MapPartitionsExec,MapElementsExec,ObjectHashAggregateExec,ProjectExec,SerializeFromObjectExec,SortExec)] - py4j.protocol.Py4JJavaError: An error occurred while calling o21328.save.
[2023-11-07T15:32:31.586Z] E                   Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: Task 6 in stage 1481.0 failed 1 times, most recent failure: Lost task 6.0 in stage 1481.0 (TID 20424) (<IP_ADDRESS> executor 0): ExecutorLostFailure (executor 0 exited caused by one of the running tasks) Reason: Executor heartbeat timed out after 130696 ms

FAILED ../../src/main/python/delta_lake_update_test.py::test_delta_update_partitions[['a']-True][INJECT_OOM, IGNORE_ORDER, ALLOW_NON_GPU(DeserializeToObjectExec,ShuffleExchangeExec,FileSourceScanExec,FilterExec,MapPartitionsExec,MapElementsExec,ObjectHashAggregateExec,ProjectExec,SerializeFromObjectExec,SortExec)] - py4j.protocol.Py4JJavaError: An error occurred while calling o28613.save.
[2023-11-07T20:03:22.336Z] : org.apache.spark.SparkException: Job aborted due to stage failure: Task 45 in stage 2227.0 failed 1 times, most recent failure: Lost task 45.0 in stage 2227.0 (TID 27324) (<IP_ADDRESS> executor 0): ExecutorLostFailure (executor 0 exited caused by one of the running tasks) Reason: Executor heartbeat timed out after 166113 ms

failed spark332

passed spark340

Steps/Code to reproduce bug
rerun internal rapids_integration-scala213-dev-github pipeline (~50% reproduciable)
Expected behavior
passed the test
Environment details (please complete the following information)

Environment location: Standalone
Spark configuration settings related to the issue

Additional context
Add any other context about the problem here.

Saw another one of these for test_repartition_df_for_round_robin, also running for spark332.

IIUC this is failing in local mode, and it's pretty odd to get an executor heartbeat timeout when the driver and executor are in the same JVM instance.  What might be happening here is that the JVM is GC'ing a lot, causing executor heartbeat timers to expire before the executor can heartbeat in time.  We saw instances of this with #9829, and I'm wondering if the fix for it in #9944 would also address this issue.  Unfortunately #9944 only went into 24.02 so far, so we'd have to check the 24.02 pipelne for scala2.13 to see if there's any improvement going forward.

IIUC this is failing in local mode, and it's pretty odd to get an executor heartbeat timeout when the driver and executor are in the same JVM instance. What might be happening here is that the JVM is GC'ing a lot, causing executor heartbeat timers to expire before the executor can heartbeat in time. We saw instances of this with #9829, and I'm wondering if the fix for it in #9944 would also address this issue. Unfortunately #9944 only went into 24.02 so far, so we'd have to check the 24.02 pipelne for scala2.13 to see if there's any improvement going forward.

Unfortunately, I think this failure has started to creep into pre-release pipelines which are running integration tests with jenkins/spark-tests.sh which is not local mode as far as I can tell. So I don't think it's specific to local mode. I'm still trying to evalute the garbage collection behavior in scala 2.12 vs 2.13 for Spark 3.3.2 here.
As far as significant different between the 3.3.2 shim and 3.4.0 shim (where the issue doesn't seem to occur), there is the shimmed versions of RapidsShuffleIterator and RapidsCachingReader
https://github.com/NVIDIA/spark-rapids/blame/branch-23.12/sql-plugin/src/main/spark311/scala/com/nvidia/spark/rapids/shuffle/RapidsShuffleIterator.scala
https://github.com/NVIDIA/spark-rapids/blame/branch-23.12/sql-plugin/src/main/spark311/scala/org/apache/spark/sql/rapids/RapidsCachingReader.scala
https://github.com/NVIDIA/spark-rapids/blame/branch-23.12/sql-plugin/src/main/spark340/scala/com/nvidia/spark/rapids/shuffle/RapidsShuffleIterator.scala
https://github.com/NVIDIA/spark-rapids/blame/branch-23.12/sql-plugin/src/main/spark340/scala/org/apache/spark/sql/rapids/RapidsCachingReader.scala
In 3.4.0, RapidsShuffleIterator uses collection.Seq (the mutable Seq in both Scala versions), and in 3.3.2 it uses scala.Seq (which is mutable in Scala 2.12, but immutable in Scala 2.13). Spark made the change in 3.4.0 to start using collection.Seq in the Shuffle

The tests described above I don't think run under the shuffle, so I am not sure that these classes are getting instantiated.

In 3.4.0, RapidsShuffleIterator uses collection.Seq (the mutable Seq in both Scala versions), and in 3.3.2 it uses scala.Seq (which is mutable in Scala 2.12, but immutable in Scala 2.13). Spark made the change in 3.4.0 to start using collection.Seq in the Shuffle

That's news to me, but don't we always use Seq in an immutable way? Even if we relied on some mutable methods, if this changed between scala versions, wouldn't scala 2.13 fail to compile that code?

In 3.4.0, RapidsShuffleIterator uses collection.Seq (the mutable Seq in both Scala versions), and in 3.3.2 it uses scala.Seq (which is mutable in Scala 2.12, but immutable in Scala 2.13). Spark made the change in 3.4.0 to start using collection.Seq in the Shuffle

That's news to me, but don't we always use Seq in an immutable way? Even if we relied on some mutable methods, if this changed between scala versions, wouldn't scala 2.13 fail to compile that code?

So we don't quite do that in all places in the code. There were a lot of places in the code where we returned something like a scala.collection.ArrayBuffer as a scala.Seq, which would compile in Scala 2.12 but fail to compile in 2.13. Scala 2.13 would definitely fail to compile unless we added a toSeq call to the return value.  In 2.13, this could potentially create a new sequence that is copied, in 2.12 this is usually a no-op which returns the existing collection.
With these new sequences being created in 2.13, it's very conceivable that there is a lot more garbage collection going on. It's possible that there will have to be further re-writing of the code for better performance under Scala 2.13.
What is interesting about these Rapids classes is not the plugins' usage of them, but the underlying Spark functionality which these graft onto. One of the big 3.4.0 changes was to start using collection.Seq in the Apache Spark shuffle code to make things a lot more efficient in terms of memory usage and speed when compiled under Scala 2.13. scala.collection.Seq exists in both Scala versions, so the code would behave exactly the same in both Scala languages.

Seeing the commit description here https://github.com/apache/spark/commit/66c6aab8f8b5168a77c86df9fa043068fc8b4b72 they describe something like .length would mean a copy in some cases. That does seem really slow and we should fix this, but I need to look at it a bit more.
Note that the shuffle classes  you pointed at (RapidsCachingReader and RapidsShuffleIterator) are only for the UCX shuffle, so I am not sure they related to this issue at hand, not to say that they shouldn't change to use collection.Seq as well, especially if we are building those spark artifacts with scala 2.13. If collection.Seq should be used throughout the code we should file an issue and get it done.
BTW, which artifacts (spark versions) are we going to compile against 2.13?

Seeing the commit description here apache/spark@66c6aab they describe something like .length would mean a copy in some cases. That does seem really slow and we should fix this, but I need to look at it a bit more.
Note that the shuffle classes you pointed at (RapidsCachingReader and RapidsShuffleIterator) are only for the UCX shuffle, so I am not sure they related to this issue at hand, not to say that they shouldn't change to use collection.Seq as well, especially if we are building those spark artifacts with scala 2.13. If collection.Seq should be used throughout the code we should file an issue and get it done.
BTW, which artifacts (spark versions) are we going to compile against 2.13?

I also filed https://github.com/NVIDIA/spark-rapids/issues/9952 to track this update. I do think this needs to be fixed in many places in our code.

Found an executor log for run 29 of the scala213 dev pipeline, and it's getting shot out of the blue:
23/12/06 10:11:28 INFO CodeGenerator: Code generated in 2.862956 ms
23/12/06 10:11:28 INFO Executor: Finished task 0.0 in stage 30339.0 (TID 96950). 163647 bytes result sent to driver
23/12/06 10:11:40 INFO CoarseGrainedExecutorBackend: Driver commanded a shutdown
23/12/06 10:11:40 INFO RapidsBufferCatalog: Closing storage
23/12/06 10:11:40 WARN GpuDeviceManager: Waiting for outstanding RMM allocations to be released...
23/12/06 10:11:40 ERROR CoarseGrainedExecutorBackend: RECEIVED SIGNAL TERM

@pxLi are we sure there aren't container memory issues?  Driver isn't shooting this, so it seems like a cgroup or OOM memory threshold thing that steps in and kills this.

Found an executor log for run 29 of the scala213 dev pipeline, and it's getting shot out of the blue:
23/12/06 10:11:28 INFO CodeGenerator: Code generated in 2.862956 ms
23/12/06 10:11:28 INFO Executor: Finished task 0.0 in stage 30339.0 (TID 96950). 163647 bytes result sent to driver
23/12/06 10:11:40 INFO CoarseGrainedExecutorBackend: Driver commanded a shutdown
23/12/06 10:11:40 INFO RapidsBufferCatalog: Closing storage
23/12/06 10:11:40 WARN GpuDeviceManager: Waiting for outstanding RMM allocations to be released...
23/12/06 10:11:40 ERROR CoarseGrainedExecutorBackend: RECEIVED SIGNAL TERM

@pxLi are we sure there aren't container memory issues? Driver isn't shooting this, so it seems like a cgroup or OOM memory threshold thing that steps in and kills this.

Should clarify, this is the log that shows this non-graceful kill:
23/12/06 08:53:02 INFO Executor: Running task 0.0 in stage 12267.0 (TID 51059)
23/12/06 08:53:02 INFO TorrentBroadcast: Started reading broadcast variable 14190 with 1 pieces (estimated total size 4.0 MiB)
23/12/06 08:53:02 INFO MemoryStore: Block broadcast_14190_piece0 stored as bytes in memory (estimated size 26.4 KiB, free 1957.1 MiB)
23/12/06 08:53:02 INFO TorrentBroadcast: Reading broadcast variable 14190 took 1 ms
23/12/06 08:53:02 INFO MemoryStore: Block broadcast_14190 stored as values in memory (estimated size 68.8 KiB, free 1957.1 MiB)
23/12/06 08:53:02 ERROR CoarseGrainedExecutorBackend: RECEIVED SIGNAL TERM
in memory (estimated size 68.8 KiB, free 1957.1 MiB)

Found an executor log for run 29 of the scala213 dev pipeline, and it's getting shot out of the blue:
23/12/06 10:11:28 INFO CodeGenerator: Code generated in 2.862956 ms
23/12/06 10:11:28 INFO Executor: Finished task 0.0 in stage 30339.0 (TID 96950). 163647 bytes result sent to driver
23/12/06 10:11:40 INFO CoarseGrainedExecutorBackend: Driver commanded a shutdown
23/12/06 10:11:40 INFO RapidsBufferCatalog: Closing storage
23/12/06 10:11:40 WARN GpuDeviceManager: Waiting for outstanding RMM allocations to be released...
23/12/06 10:11:40 ERROR CoarseGrainedExecutorBackend: RECEIVED SIGNAL TERM

@pxLi are we sure there aren't container memory issues? Driver isn't shooting this, so it seems like a cgroup or OOM memory threshold thing that steps in and kills this.

From all the failed collected metrics, the memory usage was way below the limitation (60Gi), unless there was a spike which was not caught by the metric collector in time.
Let me ask SRE to help check the failed host to see if any other unexpected processes running which could cause the issue

I have filed a ticket to SRE, and moved one suspicious bad node out of the pool for now

It appears the Spark driver+worker is the one responsible for killing the executor. From a recent scala2.13+spark332 run, the worker log has:
23/12/06 21:41:26 INFO Worker: Asked to kill executor app-20231206193627-0000/0
23/12/06 21:41:26 INFO Worker: Asked to launch executor app-20231206193627-0000/1 for rapids spark plugin integration tests (python)
23/12/06 21:41:26 INFO ExecutorRunner: Runner thread for executor app-20231206193627-0000/0 interrupted
23/12/06 21:41:26 INFO ExecutorRunner: Killing process!

and this is what the corresponding executor log has:
23/12/06 21:41:26 INFO CoarseGrainedExecutorBackend: Driver commanded a shutdown
23/12/06 21:41:26 INFO RapidsBufferCatalog: Closing storage
commanded a shutdown

So the issue is that somehow the executor heartbeats are not making it back to the driver.  It's likely either the executor heartbeat thread is stuck or died or the driver is somehow not able to receive or process the heartbeat messages in a timely manner.

Ah, this looks like a smoking gun.  In the executor log of the executor that was ultimately killed, I found this:
23/12/06 21:39:18 ERROR Utils: Uncaught exception in thread executor-heartbeater
java.util.ConcurrentModificationException: mutation occurred during iteration
        at scala.collection.mutable.MutationTracker$.checkMutations(MutationTracker.scala:43)
        at scala.collection.mutable.CheckedIndexedSeqView$CheckedIterator.hasNext(CheckedIndexedSeqView.scala:47)
        at scala.collection.mutable.Growable.addAll(Growable.scala:61)
        at scala.collection.mutable.Growable.addAll$(Growable.scala:57)
        at scala.collection.immutable.VectorBuilder.addAll(Vector.scala:1565)
        at scala.collection.immutable.Vector.appendedAll0(Vector.scala:235)
        at scala.collection.immutable.Vector1.appendedAll0(Vector.scala:427)
        at scala.collection.immutable.Vector.appendedAll(Vector.scala:203)
        at scala.collection.immutable.Vector.appendedAll(Vector.scala:113)
        at scala.collection.SeqOps.concat(Seq.scala:187)
        at scala.collection.SeqOps.concat$(Seq.scala:187)
        at scala.collection.AbstractSeq.concat(Seq.scala:1161)
        at scala.collection.IterableOps.$plus$plus(Iterable.scala:726)
        at scala.collection.IterableOps.$plus$plus$(Iterable.scala:726)
        at scala.collection.AbstractIterable.$plus$plus(Iterable.scala:926)
        at org.apache.spark.executor.TaskMetrics.accumulators(TaskMetrics.scala:261)
        at org.apache.spark.executor.Executor.$anonfun$reportHeartBeat$1(Executor.scala:1042)
        at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:563)
        at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:561)
        at scala.collection.AbstractIterable.foreach(Iterable.scala:926)
        at org.apache.spark.executor.Executor.reportHeartBeat(Executor.scala:1036)
        at org.apache.spark.executor.Executor.$anonfun$heartbeater$1(Executor.scala:238)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.scala:18)
        at org.apache.spark.util.Utils$.logUncaughtExceptions(Utils.scala:2066)
        at org.apache.spark.Heartbeater$$anon$1.run(Heartbeater.scala:46)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
        at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
        at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at java.base/java.lang.Thread.run(Thread.java:840)

Looks like the heartbeat thread died near the time that explains the heartbeat timeout.  From the driver exception:
Executor heartbeat timed out after 137823 ms

That means the last heartbeat seen by the driver was approximately at 21:41:26 - 00:02:17 = 21:39:09 which is just before the exception message seen in the executor.

This is a bug in Spark 3.3.2, fixed in Spark 3.3.3 and Spark 3.4.0 (which explains why we never see it in Spark 3.4), see SPARK-39696. We should move our Scala 2.13 pipelines off of Spark 3.3.2 and use Spark 3.3.3 as the baseline for 3.3.x testing.

Previously these 2 versions were selected to cover similar dataproc serverless runtimes. Please let us know,
1. Which shim we should use to cover previous scenarios for DP

2. Do we also need to remove 333- out of scala213 build and test list
   https://github.com/NVIDIA/spark-rapids/blob/branch-23.12/scala2.13/pom.xml#L810-L818
   https://github.com/NVIDIA/spark-rapids/blob/branch-23.12/scala2.13/pom.xml#L792-L795

@sameerz @SurajAralihalli @NVnavkumar @GaryShen2008 cc @NvTimLiu

I think the plan now would be just to replace Spark 3.3.2 scala 2.13 integration test run with Spark 3.3.3, and keep 3.4.0 and 3.5.0 runs as is. I don't think we need to update the pom files at this time (correct me if I'm wrong @jlowe)

I don't think we need to remove 3.3.2 support, but we cannot reliably test against Apache Spark 3.3.2 due to the known issue
Re: Dataproc serverless, testing against 3.3.3 should be close enough, or we would need to run against a custom Apache Spark 3.3.2 version that has the fix for SPARK-39696 applied.
Re: premerge, I do think we need to modify the pom file to adjust the premerge so we're doing a premerge against 333 instead of 332 due to the known issue with running with Spark 3.3.2 + Scala 2.1.3.  I'll post a PR to do that shortly.

I don't think we need to remove 3.3.2 support, but we cannot reliably test against Apache Spark 3.3.2 due to the known issue
Re: Dataproc serverless, testing against 3.3.3 should be close enough, or we would need to run against a custom Apache Spark 3.3.2 version that has the fix for SPARK-39696 applied.
Re: premerge, I do think we need to modify the pom file to adjust the premerge so we're doing a premerge against 333 instead of 332 due to the known issue with running with Spark 3.3.2 + Scala 2.1.3. I'll post a PR to do that shortly.

Thanks for the update!
Let me close this ticket. Feel free to reopen if require some other ops.


bug(python): OpenSSL/FIPS failure on LanceDB version 0.14.0 and higher

LanceDB version

0.13.0

What happened?
I am running LanceDB in a container on a FIPS enabled RHEL 9 machine.  I have observed that I have no issues running using version 0.13.0 of LanceDB but any version higher results in this error upon import in my python files: crypto/fips/fips.c:154: OpenSSL internal error: FATAL FIPS SELFTEST FAILURE Abort (core dumped)
Are there known steps to reproduce?
No response

Looking into this, it appears starting with v0.13.0 we started dynamically linking OpenSSL. That's generally a good security practice, though perhaps it's not configured perfectly. Will keep looking into this.
Before: v0.13.0
curl -O https://files.pythonhosted.org/packages/31/40/9b52b4da1d0c0c7cd7f91a5e10a867346104223f618ca8b7191f1a6dd32a/lancedb-0.13.0-cp38-abi3-manylinux_2_28_x86_64.whl
auditwheel show lancedb-0.13.0-cp38-abi3-manylinux_2_28_x86_64.whl

The wheel references external versioned symbols in these
system-provided shared libraries: libdl.so.2 with versions
{'GLIBC_2.2.5'}, libgcc_s.so.1 with versions {'GCC_3.0', 'GCC_4.2.0',
'GCC_3.3'}, libpthread.so.0 with versions {'GLIBC_2.12',
'GLIBC_2.2.5'}, libc.so.6 with versions {'GLIBC_2.28', 'GLIBC_2.2.5',
'GLIBC_2.14', 'GLIBC_2.15', 'GLIBC_2.7', 'GLIBC_2.3.2', 'GLIBC_2.18',
'GLIBC_2.3.4', 'GLIBC_2.3', 'GLIBC_2.8', 'GLIBC_2.25', 'GLIBC_2.17',
'GLIBC_2.4', 'GLIBC_2.9'}, libm.so.6 with versions {'GLIBC_2.27',
'GLIBC_2.2.5'}

After: v0.14.0
curl -O https://files.pythonhosted.org/packages/26/97/33e7c5f89711a2c62090fc74590827085638dd2f27dc150f4710542990c1/lancedb-0.14.0-cp38-abi3-manylinux_2_28_x86_64.whl
auditwheel show lancedb-0.14.0-cp38-abi3-manylinux_2_28_x86_64.whl

The wheel references external versioned symbols in these
system-provided shared libraries: libdl.so.2 with versions
{'GLIBC_2.2.5'}, libpthread.so.0 with versions {'GLIBC_2.2.5',
'GLIBC_2.12'}, libc.so.6 with versions {'GLIBC_2.3.2', 'GLIBC_2.14',
'GLIBC_2.7', 'GLIBC_2.17', 'GLIBC_2.3.4', 'GLIBC_2.2.5', 'GLIBC_2.28',
'GLIBC_2.15', 'GLIBC_2.3', 'GLIBC_2.25', 'GLIBC_2.8', 'GLIBC_2.16',
'GLIBC_2.9', 'GLIBC_2.18', 'GLIBC_2.4'}, libcrypto-401bea5d.so.1.1
with versions {'OPENSSL_1_1_0', 'OPENSSL_1_1_0d', 'OPENSSL_1_1_0f',
'OPENSSL_1_1_1', 'OPENSSL_1_1_0i'}, libm.so.6 with versions
{'GLIBC_2.2.5', 'GLIBC_2.27'}, libssl-52849bc7.so.1.1 with versions
{'OPENSSL_1_1_1', 'OPENSSL_1_1_0'}, libgcc_s.so.1 with versions
{'GCC_3.3', 'GCC_3.0', 'GCC_4.2.0'}

Running this on MacOS

auditwheel only runs on Linux. But it's pretty easy to set this up in docker:
docker run -it --rm -v "$(pwd):/app" -w /app python:3.11 bash

Then just need to install auditwheel and it will work:
pip install auditwheel

I believe this comes from the new remote SDK (PR), which added an HTTP library in Rust.

Tried things out on Redhat:
This suggests that we might be statically linking an older openssl: https://access.redhat.com/solutions/7035895, but I don't think we are bundling that. It seems we should be configured for dynamic linking.
@derekdereklew could you verify that you have an up-to-date openssl installation? Do other packages that use openssl work?

Looks like I'm using OpenSSL 3.0.2
Other packages that use openssl seem to import and work fine (hashlib, requests, cryptography).


Logout after running the login tests

Subsequent tests kinda depend on this assumption

Just a test change, going ahead and merging it. Comments if any - let me know.


Exotic character in menu

When you put the cursor on the title of the current section (left side menu), there seem to be an exotic character that is used. I thought I had a pretty complete set of fonts installed on my computer, so I guess a non negligible amount of people will also see this:

Could we use something else instead?

This is fixed in pull request #57 FontAwesome was broken in the version we were using for glyphs. So that has been replaced.

Ok great, thanks!