Provide ability to decorate or extend ICacheManager

I want to add some behavior (and state) to the out-of-the-box ICacheManager implementation. Normally I'd just write my own class that implements the interface, has a private field of the interface type that's passed in to the constructor, and implement the interface methods as calls to that field.
The problem is that ICacheManager has 60+ methods, making it impractical to implement. My second thought was to extend BaseCacheManager, but that class is sealed.
So I need a lightweight way to decorate the cache manager, still exposing all (well, most) of its methods. Simplest suggestion I can think of is to un-seal BaseCacheManager, but I wonder why it was sealed in the first place - maybe there's more than meets the eye in that decision.

Hi @erizzo,
I will have a look why the BaseCacheManager is sealed, not really sure why this is as I usually don't like to have any sealed classes in public APIs if possible ^^. I'll probably remove it

fixed in release 1.1.2


Dnn-8448: Support host-level OAuth authentication provider configuration

Pull request for https://dnntracker.atlassian.net/browse/DNN-8448

:+1:  looks good to me, once those couple of comments are addressed.  thanks!

The comments have been addressed. Thanks!

@jbrinkman @ashishpd is there interest in this PR?

@bdukes Definitely interest on this one, but I think it will require updates for DNN9, correct?

that's right @wmorgenweck.
@JoshuaBradley, can you check the box on this pull request to let dnnsoftware contributors edit your PR?  Thanks!

@JoshuaBradley this PR has conflicts. To be able to review, you need to go and recreate it again against the latest codebase. I will close this now without merging and feel free to submit another PR after resolving the conflicts.

@galatrash-at-dnn I've rebased and removed conflicts

@ohine I've fixed these conflicts


Weather not displaying correctly

I don´t think it´s 1692° in Vienna, Austria
This is not Fahrenheit because if it were, then it is 999° and I would probably be dead either way.
It shouuld be 17°C or 62 Fahrenheit like it´s in the MSN weather app.
Pressure, Humidity and Wind meters are fine.
Screenshot provided here:

I tried testing this by putting in the latitude/longitude of Vienna but I see the correct results. Maybe OpenWeatherMap was returning bad data? Is this still returning bad data for you?

Will check it out again when im home.


socketpair improvements

4 commits:

improvements for socketpair sample app (it was broken for a while)
minor improvements for socketpair.c
additional <fcntl.h> corrections in the networking subsystem
rename socketpair_example.c to main.c

Fixes #54347
Fixes #52360

I would really prefer to get this sample running in harness: console rather than harness: net so that we can run it on any host and have twister automatically check the output for SUCCESS using the regex property in sample.yaml. It's completely unnecessary for socketpair to depend on networking other than relying on some of the existing socket code.

@cfriedt net/lib/sockets/sockets_tls.c also needs an update.

Is there a reason why we apply this workaround:
#ifdef CONFIG_ARCH_POSIX
#include <fcntl.h>
#else
#include <zephyr/posix/fcntl.h>
#endif

to all files, but not in the <zephyr/posix/fcntl.h> header itself?

Is there a reason why we apply this workaround:
#ifdef CONFIG_ARCH_POSIX
#include <fcntl.h>
#else
#include <zephyr/posix/fcntl.h>
#endif

to all files, but not in the <zephyr/posix/fcntl.h> header itself?

Yes - because CONFIG_ARCH_POSIX and CONFIG_POSIX_API have been mutually exclusive for years. Hopefully that can be fixed soon.  It's precipitated quite a bit of spaghetti between lib/os/, subsys/net, and lib/posix. I would not recommend mixing them up again. It's actually somewhat helpful to identify where we conditionally include <fcntl.h> for native_posix as well.
Specifically w.r.t. the network subsystem though, there is a cyclic dependency between the networking subsystem and posix needs to be broken by a mutual dependency. Currently, we have:
┌───────────┐       ┌───────────┐
│           ├──────►│           │
│   POSIX   │       │   NET     │
│           │◄──────┤           │
└───────────┘       └───────────┘

But we need
          ┌───────────┐
          │           │
          │    ??     │
          │           │
          └▲────────▲─┘
           │        │
           │        │
┌──────────┴┐       ├───────────┐
│           │       │           │
│   POSIX   ├───────►   NET     │
│           │       │           │
└───────────┘       └───────────┘

I'm thinking the correct name for ?? would be something like zfdio

@cfriedt net/lib/sockets/sockets_tls.c also needs an update.

@rlubos - fixed!


Add/update OpenAI model parameters

Three changes to OpenAI model parameters

Add suffix parameter to GPT Completion models (not available for ChatGPT)
Add all other parameters to ChatCompletion models (stop, top_p, frequency_penalty, presence_penalty)
Automatically determine max output tokens based on GPT model if max_tokens not specified

Currently, the user specifies max total tokens, and then max output tokens is automatically determined by deducting the prompt tokens. This is unintuitive because

The user shouldn't have to keep track of the max total tokens for a given model
The max_tokens parameter in OpenAI models refers to the max output tokens, not max total, so we're using the phrase ambiguously here

I suggest the following, depending on whether user specifies max_tokens:

If unspecified (max_tokens=None), automatically determine max total tokens based on model name and deduct prompt tokens
If specified, simply use max_tokens as the max output tokens (aligning with how the OpenAI model uses it).

I apologize I also shuffled some other stuff around for vanity, and now it's hard to undo. I can remove those superfluous changes if you prefer.

Thanks for this Awesome PR. @eren23 Please review it, and let's merge it.

I know tested the examples we have with the changes you made, looks good to me now


add reference to node-froid for schema generation

instructions for schema generation

Closed by https://github.com/wayfair-incubator/java-froid/commit/85d6fe1975e2fde17e40fada62f7a2e04c5b2686


Pagination Missing from Metafields

Hi,
Any time you ask for metafields the gem at this point returns only 50. That has been since 2011. These days, many resources like a product could have 51 or even 251 metafields attached.
It would be nice if the code was tricked out to allow the standard paging and limits to be sent in, to get them all back.I had a fiendish time trying to figure out where my perfect code was busted, till I discovered this gem is pinned at 50.
Any input on this most appreciated. It is an oldy but a goody. Never really dealt with.

Agree that we should have this, will look into it. Thanks!

I made a version for myself that responds to
product,metafields(250, 2)

where the first value is the limit, and the second is the page, but then I replaced that style with a slower but more inclusive method called all_metafields, that pages through them all.
Any thing you guys do to improve paging will blow my crud away I am sure.
Thanks for considering this.

So I am seeing that no matter what I do, this limit of 50 is imposed by the Shopify backend. You never release more than 50 records. This is killing me! Is there a way to fast track a way to up that limit by having it respond to limits and pages without breaking your internals?
PLEASE!

Your second example would work if there were more than 50 metafields on the product, but in this case there are only 50 metafields associated with that product ID.

I will check... there should be > 50 for sure. If not something is borked
in an algorithm that does not stop at 50 but should continue infinitum...
On Thu, Oct 22, 2015 at 11:44 AM, Shayne Parmelee<EMAIL_ADDRESS>wrote:

Your second example would work if there were more than 50 metafields on
the product, but in this case there are only 50 metafields associated with
that product ID.
—
Reply to this email directly or view it on GitHub
https://github.com/Shopify/shopify_api/issues/215#issuecomment-150267155
.

I am running into this problem too, any update on this?

I fixed it.
On Saturday, 12 December 2015, flux627<EMAIL_ADDRESS>wrote:

I am running into this problem too, any update on this?
—
Reply to this email directly or view it on GitHub
https://github.com/Shopify/shopify_api/issues/215#issuecomment-164202878
.

--
Sent from Gmail Mobile

You fixed what? I can't get more than 50 results from the metafields endpoint.

You just ask for the page and limit and you get 250 per page.
On Saturday, 12 December 2015, flux627<EMAIL_ADDRESS>wrote:

You fixed what? I can't get more than 50 results from the metafields
endpoint.
—
Reply to this email directly or view it on GitHub
https://github.com/Shopify/shopify_api/issues/215#issuecomment-164208031
.


🐛 Heap does not return a new entity after persistState

No duplicates 🥲.

[X] I have searched for a similar issue in our bug tracker and didn't find any solutions.

What happened?
Hello!
Everything works excellent in simple scenarios, but there is something that does not work in a complex scenario with DDD, Command Bus, Domain Events and sync subscribers, etc.
Unfortunately, if you call EntityManagerInterface#persistState() and get persisted entity from ORM at once (I mean EntityProvider of course), then you will get null and even SQL-query. This doesn't allow separating logic by aggregate entities and persist to database atomically.
For example simple code:
$entity = new User(id: 1);
$entityManager->persistState($entity);

// There will be a search in the Heap, then a SQL query.
// Result will be null
$persistedEntity = $orm->get(User::class, ['id' => 1]);

I expect the behavior to be similar to that of Doctrine ORM, where the repository returns an entity from the unit of work cache. I also see entity being attach to the storage of Heap, but not in "paths" property. So searching for an entity in the Heap returns a empty result.
As an alternative I found a solution to get the Storage and iterate over all the entities in it.
Version
ORM 2.2.1
PHP 8.1

When you call EntityManagerInterface#persist() or EntityManagerInterface#persistState() you are working wiith separated Unit of Work that just collects entities to store.
ORM know nothing about that entities (if the are new) before you run EntityManagerInterface#run()

Thanks for answer!
Eventually, I need to make an atomic transaction, so I don't want to call run method until all important business logic has finished.
So there is no other way, but to take the entity iterator directly from Heap (instead HeapInterface)?
public class UserRepository implements UserRepositoryInterface
{
    public function get(UserId $id): User
    {
        /** @var Heap $heap */
        $heap = $this->orm->getHeap();

        foreach ($heap->getIterator() as $entity) {
            if (!$entity instanceof User) {
                continue;
            }

            if ($entity->id->equals($id)) {
                return $entity;
            }
        }

        /** @var null|User $entity */
        $entity = $this->orm->get(User::class, [
            'id' => $id,
        ]);

        return $entity ?? throw new DomainException();
    }
}

Of course, you can make your own storage for new entities, but you have to keep it clean after run/clean EntityManager. Or put entirely entities in domain events, not their IDs.
Honestly, all variations look like architectural overcomplication. Can you explain why it was designed this way please?

@roxblnfk I think we can review the idea of working with iterators/heaps based on local UoW. Since it's localized it will be much safer to predict collisions. In this particular case, the ID has not been confirmed by the database, so the local index for it does not exist.
@KorDum It was not indendend as overcomplication. Instead, the design proposes to work with local, non-intercepting transactions instead of one huge and messy heap + uow + em like in Doctrine.
The main focus is on avoiding edge cases when data can not be combined properly, for example, you created a used with the given ID and then refer it from other parts of the application. You now creating references for the object which has NOT been stored, this is OK within a single transaction, but once you span it outside of it - you can create a whole mess of side-effects when user can't be properly committed.
One of the options I can suggest - we can build local indexes on a level of UoW/EM itself, which seems much more logical instead of going back to Heap.

Thanks!
So I thought it was for separation.
It would be nice to have a cleaner and more "high level" API for getting an entity from a local UoW.

Converted to https://github.com/cycle/orm/issues/436


WPA3 probably not workgin

On the MDP image that we created internally we ran into the issue that the wifi-connect is not working as soon as there is a WPA3 network floating around.  This seems to be an issue with wifi-connect. We need to check to what extend we are facing this issue as well.

Connecting to any other network when there is a WPA3 in the air works with the latest image.
Connecting to the WPA3 network is not yet possible, will give a Error: Connection activation failed: (53) The Wi-Fi network could not be found. error.


Javascript and CSS include errors

I am trying to create a router with the Path: localhost/user/login.  Here is an example how I try to do it: $router->add('user/login', ['controller' => 'LoginController', 'action' => 'login']);
It also works but I get include errors from Javascript freamworks and CSS. See the picture.

Includes in the twig file:

...
...
If I only use e.g. "login" as path the frameworks are included.
$router->add('user/login', ['controller' => 'LoginController', 'action' => 'login']);

The URLs for your included files need to be based on the path to the public folder - so for example if you have a file pubic/css/main.css, you would include it like this:
<link rel="stylesheet" href="/css/main.css">
If you have the framework in a subfolder, you need to include that too:
<link rel="stylesheet" href="/appmvc/css/main.css">


allow storing tls certs directly in --log-opt for syslog

Right now the syslog driver takes paths to TLS certs. See docs. This works fine for a container because you know exactly where it'll run and you can prepare that one machine ahead of time, but when used with a service, you need a separate mechanism for distributing TLS certs across the cluster. It would make using the syslog log driver in swarm mode much easier if you could put the cert directly in the cli argument like so:
docker service create --log-driver syslog --log-opt syslog-address=tcp+tls://url:11111 --log-opt syslog-tls-ca-cert-pem="$(cat cert.pem)" --name registry --publish <IP_ADDRESS>:5000:5000 registry:2

Almost tempted to say it should use the "secrets" feature in SwarmKit, but that won't work, because the logging drivers run outside the container.
Would this be a job for InfraKit? i.e., install certificates on the nodes
@wfarner @chungers wdyt?

Ping? We still don't have a good way to manage syslog certs.

I would think we would want to inject this via a secret rather than cating directly.

/cc @cyli @diogomonica

How would the log-driver access this secret? I don't know enough about how they work to have good ideas here. Right now secrets appear in containers, and will also be supported by plugins.
Someone that knows more about how log drivers work should help me figure this out.

I guess this would need plugin support for secrets, and logging drivers to be moved to plugins (https://github.com/docker/docker/pull/28403)

We'd have to make it work for sure, but passing the secret when the driver fires up (once per container) seems like it'd be ok assuming we are in swarm mode.

Now that logging drivers have been improved, do you guys have an idea for how we can distribute certs for them?

@vikstrous We still need to figure out how we'd pass down a secret for a log driver.
With plugins on swarm we should (with a recent swarmkit merge) be able to request secrets for the plugin and inject into the plugin container.
So I think specifically for plugins (running on swarm) it will be easier (essentially free) to get secrets for the plugin.
For the in-memory drivers it's a bit more tough. Maybe a swarm service can define that it needs a secret for the logging driver, and let the worker determine how to handle that.

Reading back the original proposal; We should probably be careful implementing this as proposed, as there's definitely a risk of people specifying the secrets as literal values (syslog-tls-ca-cert-pem="value here"), ending up with those values being logged somewhere


First Unique Charachter of a string

Hi, I am a participant of Hacktoberfest. I would like to add this question in strings. Kindly assign me this issue. Thank you.
Question: Given a string s, find the first non-repeating character in it and return its index. If it does not exist, return -1.
Input: s = "aabb"
Output: -1
Input: s = "code"
Output: 0

Can i do this plzz assign me , I will be very grateful....

Plz, Assign me i have the solution ready

@ASLManasa
Go ahead :)

@ZeelParekh10  Create your own issue will assign you surely :)


I can't solve permition iroha2 tutorial

root@localhost:/usr/local/src/iroha/test_docker# ./iroha_client_cli account grant --id "mad_hatter@looking_glass" --permission permission_token.json
error: Invalid value "permission_token.json" for '--permission ': Failed to deserialize the permission token from file permission_token.json
root@localhost:/usr/local/src/iroha/test_docker# cat permission_token.json
{"definition_id":"can_transfer_user_assets","params":{"asset_id":{"Id":{"AssetId":"tea#looking_glass"}},"account_id":{"Id":{"AccountId":"mad_hatter@looking_glass"}}}}
Command out put
[
Asset {
id: Id {
definition_id: DefinitionId {
name: "tea",
domain_id: Id {
name: "looking_glass",
},
},
account_id: Id {
name: "mad_hatter",
domain_id: Id {
name: "looking_glass",
},
},
},
value: Quantity(
2300,
),
},
Asset {
id: Id {
definition_id: DefinitionId {
name: "cabbage",
domain_id: Id {
name: "garden_of_live_flowers",
},
},
account_id: Id {
name: "alice",
domain_id: Id {
name: "wonderland",
},
},
},
value: Quantity(
44,
),
},
Asset {
id: Id {
definition_id: DefinitionId {
name: "rose",
domain_id: Id {
name: "wonderland",
},
},
account_id: Id {
name: "alice",
domain_id: Id {
name: "wonderland",
},
},
},
value: Quantity(
13,
),
},
]

Hello! Our tutorial is still a work in progress, so it is not completely up to date yet. Asset ids are made of account id and asset definition id. That is, both these fields should be specified for it to parse properly.
There is a shorthand notation to specify both of these ids in a single string. It could either be "asset_name#asset_domain#account_name@account_domain", or an even shorter version when asset's domain and account's domain are equal, as it is in your case: "asset_name##account_name@account_domain".
So most ergonomically permission.json only needs to contain this:
{
  "definition_id": "can_transfer_user_assets",
  "params": {
    "asset_id": {
      "Id": {
        "AssetId": "tea##mad_hatter@looking_glass"
      }
    }
  }
}


add conditional support for countries and country_select

This PR is related with issue https://github.com/sferik/rails_admin/issues/1929. I have added support for field type :country

Sorry for delay, test code and rebase are needed!

Please reopen on update.


Writing large parquet files to public S3 bucket with pyarrow failing

I'm running into issues when writing larger datasets to parquet into a public S3 bucket with the code snippet below.
tl;dr
Small, dummy datasets work (see "This Works" section below) but larger timeseries dataframe (thousands of partitions) fails (see "This Fails" section) with a KilledWorker error. Writing to_csv works for both the small and the large datasets.
IMPORTS AND SPINNING UP CLUSTER
import coiled
import dask.dataframe as dd
from dask.distributed import Client
import dask

cluster = coiled.Cluster(
    name="data-import",
    software='rrpelgrim/create-coiled-datasets-m1-test',
    n_workers=20,
    worker_cpu=4,
    worker_memory='32Gb',
    scheduler_cpu=2,
    shutdown_on_close=False,
    scheduler_options={'idle_timeout':'1hour'},
)

client = Client(cluster)
client

THIS WORKS
from pandas import DataFrame, to_datetime
from dask.dataframe import from_pandas

df = DataFrame({
     "index": ["1", "2", "3", "2", "3", "1", "4"],
     "date":  to_datetime(["2017-01-01", "2017-01-01", "2017-01-01", "2017-01-02", "2017-01-02",
                                            "2017-01-06", "2017-01-09"]),
     "amount": [100, 200, 300, 400, 500, 600, 700]
    }
)

df = from_pandas(df, npartitions=2).set_index("index")

df.to_parquet(
    "s3://path/to/bucket/small-dummy.parquet",
    engine='pyarrow',
    schema='infer'
)

THIS FAILS
df2 = dask.datasets.timeseries("1950") # defaults to 18K partitions in my case

df2.to_parquet(
    "s3://path/to/bucket/large-dummy.parquet",
    engine='pyarrow',
    schema='infer'
)

I get a warning when I run the cell:
/Users/rpelgrim/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/distributed/worker.py:3801: UserWarning: Large object of size 0.98 MiB detected in task graph:
  [["('to-parquet-080c68ea005907e78bc9e4b3cbc2a96f', ... dummy.parquet']
Consider scattering large objects ahead of time
with client.scatter to reduce scheduler burden and
keep data on workers

    future = client.submit(func, big_data)    # bad

    big_future = client.scatter(big_data)     # good
    future = client.submit(func, big_future)  # good
  warnings.warn(

And the cell ends up throwing an error after killing and restarting workers a few times:
---------------------------------------------------------------------------
KilledWorker                              Traceback (most recent call last)
<ipython-input-12-559d4aeda91a> in <module>
----> 1 data.to_parquet(
      2     "s3://coiled-datasets/dea-opioid/tests/dummy.parquet",
      3     engine='pyarrow',
      4     schema='infer'
      5 )

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/dask/dataframe/core.py in to_parquet(self, path, *args, **kwargs)
   4451         from .io import to_parquet
   4452
-> 4453         return to_parquet(self, path, *args, **kwargs)
   4454
   4455     @derived_from(pd.DataFrame)

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/dask/dataframe/io/parquet/core.py in to_parquet(df, path, engine, compression, write_index, append, overwrite, ignore_divisions, partition_on, storage_options, custom_metadata, write_metadata_file, compute, compute_kwargs, schema, **kwargs)
    719         if compute_kwargs is None:
    720             compute_kwargs = dict()
--> 721         out = out.compute(**compute_kwargs)
    722     return out
    723

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/dask/base.py in compute(self, **kwargs)
    284         dask.base.compute
    285         """
--> 286         (result,) = compute(self, traverse=False, **kwargs)
    287         return result
    288

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/dask/base.py in compute(*args, **kwargs)
    566         postcomputes.append(x.__dask_postcompute__())
    567
--> 568     results = schedule(dsk, keys, **kwargs)
    569     return repack([f(r, *a) for r, (f, a) in zip(results, postcomputes)])
    570

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/distributed/client.py in get(self, dsk, keys, workers, allow_other_workers, resources, sync, asynchronous, direct, retries, priority, fifo_timeout, actors, **kwargs)
   2741                     should_rejoin = False
   2742             try:
-> 2743                 results = self.gather(packed, asynchronous=asynchronous, direct=direct)
   2744             finally:
   2745                 for f in futures.values():

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/distributed/client.py in gather(self, futures, errors, direct, asynchronous)
   2018             else:
   2019                 local_worker = None
-> 2020             return self.sync(
   2021                 self._gather,
   2022                 futures,

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/distributed/client.py in sync(self, func, asynchronous, callback_timeout, *args, **kwargs)
    859             return future
    860         else:
--> 861             return sync(
    862                 self.loop, func, *args, callback_timeout=callback_timeout, **kwargs
    863             )

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/distributed/utils.py in sync(loop, func, callback_timeout, *args, **kwargs)
    324     if error[0]:
    325         typ, exc, tb = error[0]
--> 326         raise exc.with_traceback(tb)
    327     else:
    328         return result[0]

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/distributed/utils.py in f()
    307             if callback_timeout is not None:
    308                 future = asyncio.wait_for(future, callback_timeout)
--> 309             result[0] = yield future
    310         except Exception:
    311             error[0] = sys.exc_info()

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/tornado/gen.py in run(self)
    760
    761                     try:
--> 762                         value = future.result()
    763                     except Exception:
    764                         exc_info = sys.exc_info()

~/mambaforge/envs/create-coiled-datasets-m1/lib/python3.9/site-packages/distributed/client.py in _gather(self, futures, errors, direct, local_worker)
   1883                             exc = CancelledError(key)
   1884                         else:
-> 1885                             raise exception.with_traceback(traceback)
   1886                         raise exc
   1887                     if errors == "skip":

KilledWorker: ("('make-timeseries-436c2767977bc3b5d6a88d86e1bbb3fb', 14872)", <WorkerState 'tls://<IP_ADDRESS>:34063', name: coiled-rrpelgr71-36483-worker-638cc5c13e, memory: 0, processing: 1050>)

I'm running:
MacOS 11.3.1 (Macbook pro 2020, M1 chip).
Python: 3.9.6
Dask: 2021.07.1
Distributed: 2021.07.1
Pyarrow: 5.0.0
FWIW this workaround suggested to me by @fjetter does work:
def submit_jobs():
    from distributed import get_client

    with get_client() as client:
        data = dask.datasets.timeseries(
            start="1950",
            end="1951",
        )
        data.to_parquet(
            "s3://coiled-datasets/dea-opioid/tests/dummy-timeseries-170821-2.parquet",
            engine='fastparquet',
        )
        data.compute()

client.submit(submit_jobs).result()

cc @jorisvandenbossche I looked a bit into this and it turns out to be a segmenetation fault on pyarrow side. I couldn't find out more, yet, but if you have a suggestion on how to debug this, that's much appreciated.

AFAICT just some garbage collection info messages that seem out of the ordinary. Copying the full logs of 1 worker below:
[    6.421534] cloud-init[354]: Cloud-init v. 20.3-15-g6d332e5c-0ubuntu1 running 'init-local' at Mon, 13 Sep 2021 09:55:47 +0000. Up 5.96 seconds.
[  OK  ] Finished Initial cloud-init job (pre-networking).
[    9.476423] cloud-init[411]: Cloud-init v. 20.3-15-g6d332e5c-0ubuntu1 running 'init' at Mon, 13 Sep 2021 09:55:50 +0000. Up 9.36 seconds.
[    9.480065] cloud-init[411]: ci-info: ++++++++++++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++++++++++++
[    9.483459] cloud-init[411]: ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[    9.486877] cloud-init[411]: ci-info: | Device |  Up  |          Address           |      Mask     | Scope  |     Hw-Address    |
[    9.490100] cloud-init[411]: ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[    9.493601] cloud-init[411]: ci-info: |  ens5  | True |        <IP_ADDRESS>         | <IP_ADDRESS> | global | 02:7c:4a:2a:ff:55 |
[    9.496623] cloud-init[411]: ci-info: |  ens5  | True | fe80::7c:4aff:fe2a:ff55/64 |       .       |  link  | 02:7c:4a:2a:ff:55 |
[    9.500133] cloud-init[411]: ci-info: |   lo   | True |         <IP_ADDRESS>          |   <IP_ADDRESS>   |  host  |         .         |
[    9.503624] cloud-init[411]: ci-info: |   lo   | True |          ::1/128           |       .       |  host  |         .         |
[    9.507069] cloud-init[411]: ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
[    9.510066] cloud-init[411]: ci-info: +++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++
[    9.512821] cloud-init[411]: ci-info: +-------+-------------+-----------+-----------------+-----------+-------+
[    9.515660] cloud-init[411]: ci-info: | Route | Destination |  Gateway  |     Genmask     | Interface | Flags |
[    9.518494] cloud-init[411]: ci-info: +-------+-------------+-----------+-----------------+-----------+-------+
[    9.521161] cloud-init[411]: ci-info: |   0   |   <IP_ADDRESS>   | <IP_ADDRESS> |     <IP_ADDRESS>     |    ens5   |   UG  |
[    9.524375] cloud-init[411]: ci-info: |   1   |  <IP_ADDRESS>  |  <IP_ADDRESS>  |  <IP_ADDRESS>  |    ens5   |   U   |
[    9.527746] cloud-init[411]: ci-info: |   2   |  <IP_ADDRESS>  |  <IP_ADDRESS>  | <IP_ADDRESS> |    ens5   |   UH  |
[    9.530381] cloud-init[411]: ci-info: +-------+-------------+-----------+-----------------+-----------+-------+
[    9.532582] cloud-init[411]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
[    9.534493] cloud-init[411]: ci-info: +-------+-------------+---------+-----------+-------+
[    9.536366] cloud-init[411]: ci-info: | Route | Destination | Gateway | Interface | Flags |
[    9.538203] cloud-init[411]: ci-info: +-------+-------------+---------+-----------+-------+
[    9.540813] cloud-init[411]: ci-info: |   1   |  fe80::/64  |    ::   |    ens5   |   U   |
[    9.543769] cloud-init[411]: ci-info: |   3   |    local    |    ::   |    ens5   |   U   |
[    9.546700] cloud-init[411]: ci-info: |   4   |   ff00::/8  |    ::   |    ens5   |   U   |
[    9.549285] cloud-init[411]: ci-info: +-------+-------------+---------+-----------+-------+
[   10.749658] cloud-init[411]: Generating public/private rsa key pair.
[   10.751400] cloud-init[411]: Your identification has been saved in /etc/ssh/ssh_host_rsa_key
[   10.753424] cloud-init[411]: Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub
[   10.755404] cloud-init[411]: The key fingerprint is:
[   10.756509] cloud-init[411]: SHA256:sxY/sOh+ZP5T5gcSbiZWzvCWFpOBpLFs7blf/L8z9rg root@ip-10-4-25-103
[   10.758512] cloud-init[411]: The key's randomart image is:
[   10.759762] cloud-init[411]: +---[RSA 3072]----+
[   10.760913] cloud-init[411]: |      ....       |
[   10.761986] cloud-init[411]: |     . =. .      |
[   10.763166] cloud-init[411]: |      = .  o     |
[   10.764234] cloud-init[411]: |     . ...*      |
[   10.765468] cloud-init[411]: |        SB =     |
[   10.766543] cloud-init[411]: |       .=O%.+    |
[   10.767605] cloud-init[411]: |      .==*o=o.   |
[   10.768687] cloud-init[411]: |     . .o..o...= |
[   10.769794] cloud-init[411]: |     .o. .o. .E+B|
[   10.771019] cloud-init[411]: +----[SHA256]-----+
[   10.772061] cloud-init[411]: Generating public/private dsa key pair.
[   10.773584] cloud-init[411]: Your identification has been saved in /etc/ssh/ssh_host_dsa_key
[   10.775433] cloud-init[411]: Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub
[   10.777284] cloud-init[411]: The key fingerprint is:
[   10.778405] cloud-init[411]: SHA256:2eJbcHsi6u5otQjJsoWWQ12QUTvZUVrNowO1d4rzcbQ root@ip-10-4-25-103
[   10.780506] cloud-init[411]: The key's randomart image is:
[   10.781803] cloud-init[411]: +---[DSA 1024]----+
[   10.782867] cloud-init[411]: |   o=. .o+o      |
[   10.783921] cloud-init[411]: |   . .+.+ .+     |
[   10.784994] cloud-init[411]: |  . .+ o.....o   |
[   10.786045] cloud-init[411]: | . .  .  =o + .  |
[   10.787184] cloud-init[411]: |.o..    So+o E   |
[   10.788262] cloud-init[411]: |o+=   .. +o.o    |
[   10.789404] cloud-init[411]: |.+.. o .o +..    |
[   10.790506] cloud-init[411]: |.   o... + o     |
[   10.791607] cloud-init[411]: |   ..+= .        |
[   10.792749] cloud-init[411]: +----[SHA256]-----+
[   10.793860] cloud-init[411]: Generating public/private ecdsa key pair.
[   10.795306] cloud-init[411]: Your identification has been saved in /etc/ssh/ssh_host_ecdsa_key
[   10.797190] cloud-init[411]: Your public key has been saved in /etc/ssh/ssh_host_ecdsa_key.pub
[   10.799040] cloud-init[411]: The key fingerprint is:
[   10.800303] cloud-init[411]: SHA256:CQR/l1vdKQbkX1hmkcQXO27R4Vhw3n46GH0iLTYBWC0 root@ip-10-4-25-103
[   10.802274] cloud-init[411]: The key's randomart image is:
[   10.803599] cloud-init[411]: +---[ECDSA 256]---+
[   10.804674] cloud-init[411]: |    ...  o++ .+@+|
[   10.805760] cloud-init[411]: |     o  . Eoo.@+B|
[   10.806944] cloud-init[411]: |      o . ooo=.O=|
[   10.808034] cloud-init[411]: |       o o oo++.o|
[   10.809110] cloud-init[411]: |        S . *.+o+|
[   10.810165] cloud-init[411]: |           . *.+.|
[   10.811239] cloud-init[411]: |            . o  |
[   10.812361] cloud-init[411]: |               . |
[   10.813468] cloud-init[411]: |                 |
[   10.814532] cloud-init[411]: +----[SHA256]-----+
[   10.815649] cloud-init[411]: Generating public/private ed25519 key pair.
[   10.817134] cloud-init[411]: Your identification has been saved in /etc/ssh/ssh_host_ed25519_key
[   10.819033] cloud-init[411]: Your public key has been saved in /etc/ssh/ssh_host_ed25519_key.pub
[   10.820963] cloud-init[411]: The key fingerprint is:
[   10.822217] cloud-init[411]: SHA256:aWqBQWj2rXNBdEpGALkQJV2hWtGmNkNZnOeIARDWq7w root@ip-10-4-25-103
[   10.824252] cloud-init[411]: The key's randomart image is:
[   10.825632] cloud-init[411]: +--[ED25519 256]--+
[   10.826707] cloud-init[411]: |BB=X**= .        |
[   10.827868] cloud-init[411]: |o.X==ooo         |
[   10.828992] cloud-init[411]: | =oBo*.          |
[   10.830179] cloud-init[411]: | oB.oo+  .       |
[   10.831246] cloud-init[411]: |o..o....S        |
[   10.832453] cloud-init[411]: | o  o .+         |
[   10.833607] cloud-init[411]: |  .  oo          |
[   10.834763] cloud-init[411]: | E   .           |
[   10.835906] cloud-init[411]: |                 |
[   10.837073] cloud-init[411]: +----[SHA256]-----+
ip-10-4-25-103 login: [   17.151484] cloud-init[967]: Cloud-init v. 20.3-15-g6d332e5c-0ubuntu1 running 'modules:config' at Mon, 13 Sep 2021 09:55:58 +0000. Up 16.59 seconds.
[   17.459751] cloud-init[982]: COILED SERVER IS: https://cloud.coiled.io
[   17.461923] cloud-init[982]: Token ****
[   17.464390] cloud-init[982]: Data:
[   17.469563] cloud-init[982]:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[   17.472369] cloud-init[982]:                                  Dload  Upload   Total   Spent    Left  Speed
[   17.474759] cloud-init[982]:
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <IP_ADDRESS>:443...
[   17.477446] cloud-init[982]: * TCP_NODELAY set
[   17.487531] cloud-init[982]: * Connected to cloud.coiled.io (<IP_ADDRESS>) port 443 (#0)
[   17.490155] cloud-init[982]: * ALPN, offering h2
[   17.491888] cloud-init[982]: * ALPN, offering http/1.1
[   17.494025] cloud-init[982]: * successfully set certificate verify locations:
[   17.495947] cloud-init[982]: *   CAfile: /etc/ssl/certs/ca-certificates.crt
[   17.497555] cloud-init[982]:   CApath: /etc/ssl/certs
[   17.498805] cloud-init[982]: } [5 bytes data]
[   17.499938] cloud-init[982]: * TLSv1.3 (OUT), TLS handshake, Client hello (1):
[   17.501601] cloud-init[982]: } [512 bytes data]
[   17.508054] cloud-init[982]: * TLSv1.3 (IN), TLS handshake, Server hello (2):
[   17.509751] cloud-init[982]: { [98 bytes data]
[   17.509917] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Certificate (11):
[   17.510229] cloud-init[982]: { [4934 bytes data]
[   17.510522] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
[   17.510829] cloud-init[982]: { [333 bytes data]
[   17.511120] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Server finished (14):
[   17.511438] cloud-init[982]: { [4 bytes data]
[   17.511808] cloud-init[982]: * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
[   17.512124] cloud-init[982]: } [70 bytes data]
[   17.512466] cloud-init[982]: * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
[   17.512775] cloud-init[982]: } [1 bytes data]
[   17.513087] cloud-init[982]: * TLSv1.2 (OUT), TLS handshake, Finished (20):
[   17.513423] cloud-init[982]: } [16 bytes data]
[   17.526790] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Finished (20):
[   17.529073] cloud-init[982]: { [16 bytes data]
[   17.530213] cloud-init[982]: * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
[   17.532107] cloud-init[982]: * ALPN, server accepted to use h2
[   17.533481] cloud-init[982]: * Server certificate:
[   17.534733] cloud-init[982]: *  subject: CN=cloud.coiled.io
[   17.536133] cloud-init[982]: *  start date: Aug 22 00:00:00 2021 GMT
[   17.537640] cloud-init[982]: *  expire date: Sep 20 23:59:59 2022 GMT
[   17.539216] cloud-init[982]: *  subjectAltName: host "cloud.coiled.io" matched cert's "cloud.coiled.io"
[   17.541641] cloud-init[982]: *  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
[   17.543403] cloud-init[982]: *  SSL certificate verify ok.
[   17.544711] cloud-init[982]: * Using HTTP2, server supports multi-use
[   17.546229] cloud-init[982]: * Connection state changed (HTTP/2 confirmed)
[   17.547784] cloud-init[982]: * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
[   17.550072] cloud-init[982]: } [5 bytes data]
[   17.551179] cloud-init[982]: * Using Stream ID: 1 (easy handle 0x5573a997ad50)
[   17.552875] cloud-init[982]: } [5 bytes data]
[   17.554019] cloud-init[982]: > POST /api/v1/rrpelgrim/notifications/ HTTP/2
[   17.555606] cloud-init[982]: > Host: cloud.coiled.io
[   17.556774] cloud-init[982]: > user-agent: curl/7.68.0
[   17.558036] cloud-init[982]: > accept: */*
[   17.559054] cloud-init[982]: > content-type: application/json
[   17.560396] cloud-init[982]: > authorization: Token ****
[   17.562333] cloud-init[982]: > content-length: 256
[   17.563479] cloud-init[982]: >
[   17.564293] cloud-init[982]: { [5 bytes data]
[   17.565410] cloud-init[982]: * Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
[   17.567206] cloud-init[982]: } [5 bytes data]
[   17.568275] cloud-init[982]: * We are completely uploaded and fine
[   17.569756] cloud-init[982]: { [5 bytes data]
[   17.578186] cloud-init[982]: < HTTP/2 200
[   17.578258] cloud-init[982]: < date: Mon, 13 Sep 2021 09:55:59 GMT
[   17.581431] cloud-init[982]: < content-type: application/json
[   17.583564] cloud-init[982]: < content-length: 331
[   17.585306] cloud-init[982]: < server: uvicorn
[   17.586865] cloud-init[982]: < vary: Accept, Origin
[   17.588728] cloud-init[982]: < allow: GET, POST, HEAD, OPTIONS
[   17.590996] cloud-init[982]: < x-frame-options: DENY
[   17.592761] cloud-init[982]: < x-content-type-options: nosniff
[   17.594903] cloud-init[982]: < referrer-policy: same-origin
[   17.596377] cloud-init[982]: <
[   17.597358] cloud-init[982]: { [331 bytes data]
[   17.598535] cloud-init[982]:
100   587  100   331  100   256   3036   2348 --:--:-- --:--:-- --:--:--  5385
[   17.600675] cloud-init[982]: * Connection #0 to host cloud.coiled.io left intact
[   17.602434] cloud-init[982]: {"msg":"coiled-dask-rrpelgr71-44751-worker: VM Launched","data":{"vm_label":"coiled-dask-rrpelgr71-44751-worker"},"id":"0042ee","username":"rrpelgrim","account":"rrpelgrim","level":20,"event_type":"vm_event","logging_context":{"view.name":"django.view.POST","user.username":"rrpelgrim","user.id":1292,"user.is_authenticated":true}}
[   17.609770] cloud-init[982]: MachineType
[   17.610889] cloud-init[982]: m5zn.large
[   17.622507] cloud-init[982]: --2021-09-13 09:55:59--  https://cloud.coiled.io/scripts/cloudwatch.sh
[   17.625033] cloud-init[982]: Resolving cloud.coiled.io (cloud.coiled.io)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>
[   17.637358] cloud-init[982]: Connecting to cloud.coiled.io (cloud.coiled.io)|<IP_ADDRESS>|:443... connected.
[   17.688116] cloud-init[982]: HTTP request sent, awaiting response... 200 OK
[   17.690396] cloud-init[982]: Length: 1279 (1.2K) [text/x-sh]
[   17.692720] cloud-init[982]: Saving to: ‘cloudwatch.sh’
[   17.695004] cloud-init[982]:      0K .                                                     100%  269M=0s
[   17.698469] cloud-init[982]: 2021-09-13 09:55:59 (269 MB/s) - ‘cloudwatch.sh’ saved [1279/1279]
[   17.708289] cloud-init[982]:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[   17.708356] cloud-init[982]:                                  Dload  Upload   Total   Spent    Left  Speed
[   18.347760] cloud-init[982]:
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
 44 57.5M   44 25.5M    0     0  87.6M      0 --:--:-- --:--:-- --:--:-- 87.3M
100 57.5M  100 57.5M    0     0  89.8M      0 --:--:-- --:--:-- --:--:-- 89.8M
[   18.427640] cloud-init[982]: Selecting previously unselected package amazon-cloudwatch-agent.
[   18.997075] cloud-init[982]: (Reading database ... 64914 files and directories currently installed.)
[   19.005139] cloud-init[982]: Preparing to unpack .../amazon-cloudwatch-agent.deb ...
[   19.065472] cloud-init[982]: create group cwagent, result: 0
[   19.160677] cloud-init[982]: create user cwagent, result: 0
[   19.162709] cloud-init[982]: Unpacking amazon-cloudwatch-agent (1.247349.0b251399-1) ...
[   23.360464] cloud-init[982]: Setting up amazon-cloudwatch-agent (1.247349.0b251399-1) ...
[   23.491719] cloud-init[982]: Created symlink /etc/systemd/system/multi-user.target.wants/amazon-cloudwatch-agent.service → /etc/systemd/system/amazon-cloudwatch-agent.service.
[   24.435259] cloud-init[982]: --2021-09-13 09:56:06--  https://raw.githubusercontent.com/moby/moby/d39b075302c27f77b2de413697a5aacb034d8286/profiles/seccomp/default.json
[   24.443526] cloud-init[982]: Resolving raw.githubusercontent.com (raw.githubusercontent.com)... <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, ...
[   24.451826] cloud-init[982]: Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|<IP_ADDRESS>|:443... connected.
[   24.468408] cloud-init[982]: HTTP request sent, awaiting response... 200 OK
[   24.468493] cloud-init[982]: Length: 12958 (13K) [text/plain]
[   24.468548] cloud-init[982]: Saving to: ‘default.json’
[   24.472542] cloud-init[982]:      0K .......... ..                                         100% 3.04M=0.004s
[   24.472624] cloud-init[982]: 2021-09-13 09:56:06 (3.04 MB/s) - ‘default.json’ saved [12958/12958]
[   24.478696] cloud-init[982]: COILED SERVER IS: https://cloud.coiled.io
[   25.239772] cloud-init[982]: Pulling dask ...
[   65.443500] cloud-init[982]:
Pulling dask ... pulling from prod/coiled-examples...

Pulling dask ... pulling fs layer

Pulling dask ... pulling fs layer

Pulling dask ... pulling fs layer

Pulling dask ... pulling fs layer

Pulling dask ... pulling fs layer

Pulling dask ... pulling fs layer

Pulling dask ... waiting

Pulling dask ... waiting

Pulling dask ... waiting

Pulling dask ... downloading (1.0%)

Pulling dask ... downloading (0.6%)

Pulling dask ... downloading (1.0%)

Pulling dask ... downloading (32.3%)

Pulling dask ... downloading (10.2%)

Pulling dask ... downloading (6.8%)

Pulling dask ... downloading (58.3%)

Pulling dask ... downloading (17.2%)

Pulling dask ... downloading (15.6%)

Pulling dask ... downloading (80.2%)
[2021-09-13T09:56:47.088601]
Pulling dask ... downloading (22.3%)

Pulling dask ... downloading (26.4%)

Pulling dask ... verifying checksum

Pulling dask ... download complete

Pulling dask ... downloading (28.0%)

Pulling dask ... downloading (42.0%)

Pulling dask ... extracting (1.0%)

Pulling dask ... downloading (48.8%)

Pulling dask ... downloading (32.5%)

Pulling dask ... downloading (0.8%)

Pulling dask ... downloading (5.0%)

Pulling dask ... downloading (59.6%)

Pulling dask ... extracting (3.1%)

Pulling dask ... downloading (40.8%)

Pulling dask ... downloading (67.4%)

Pulling dask ... downloading (12.5%)

Pulling dask ... downloading (45.9%)

Pulling dask ... downloading (76.2%)

Pulling dask ... downloading (51.0%)

Pulling dask ... downloading (18.4%)
[2021-09-13T09:56:47.088630]
Pulling dask ... downloading (85.1%)

Pulling dask ... downloading (60.6%)

Pulling dask ... extracting (5.2%)

Pulling dask ... downloading (24.2%)

Pulling dask ... downloading (93.9%)

Pulling dask ... downloading (65.7%)

Pulling dask ... downloading (30.1%)

Pulling dask ... extracting (7.3%)

Pulling dask ... verifying checksum

Pulling dask ... download complete

Pulling dask ... downloading (70.1%)

Pulling dask ... downloading (36.8%)

Pulling dask ... downloading (74.6%)

Pulling dask ... downloading (41.8%)

Pulling dask ... downloading (100.0%)

Pulling dask ... verifying checksum

Pulling dask ... download complete

Pulling dask ... extracting (9.3%)

Pulling dask ... downloading (78.4%)

Pulling dask ... downloading (46.8%)

Pulli[2021-09-13T09:56:47.088671]ng dask ... extracting (10.4%)

Pulling dask ... downloading (88.0%)

Pulling dask ... downloading (53.5%)

Pulling dask ... downloading (0.1%)

Pulling dask ... downloading (91.8%)

Pulling dask ... extracting (12.5%)

Pulling dask ... downloading (1.0%)

Pulling dask ... downloading (60.2%)

Pulling dask ... downloading (67.7%)

Pulling dask ... downloading (96.3%)

Pulling dask ... verifying checksum

Pulling dask ... download complete

Pulling dask ... downloading (2.2%)

Pulling dask ... extracting (14.5%)

Pulling dask ... downloading (82.8%)

Pulling dask ... downloading (3.9%)

Pulling dask ... verifying checksum

Pulling dask ... download complete

Pulling dask ... extracting (16.6%)

Pulling dask ... downloading (6.4%)

Pulling dask ..[2021-09-13T09:56:47.088708]. extracting (25.9%)

Pulling dask ... downloading (10.8%)

Pulling dask ... extracting (31.1%)

Pulling dask ... downloading (15.4%)

Pulling dask ... extracting (41.5%)

Pulling dask ... downloading (18.7%)

Pulling dask ... extracting (48.8%)

Pulling dask ... downloading (21.4%)

Pulling dask ... extracting (59.2%)

Pulling dask ... downloading (24.0%)

Pulling dask ... extracting (69.5%)

Pulling dask ... downloading (27.6%)

Pulling dask ... extracting (79.9%)

Pulling dask ... downloading (31.2%)

Pulling dask ... extracting (86.1%)

Pulling dask ... downloading (33.3%)

Pulling dask ... downloading (34.7%)

Pulling dask ... extracting (91.3%)

Pulling dask ... downloading (35.6%)

Pulling dask ... extracting (93.4%)

Pulling dask ... dow[2021-09-13T09:56:47.088736]nloading (37.7%)

Pulling dask ... extracting (95.5%)

Pulling dask ... downloading (39.8%)

Pulling dask ... downloading (41.7%)

Pulling dask ... downloading (43.5%)

Pulling dask ... extracting (96.5%)

Pulling dask ... downloading (44.7%)

Pulling dask ... extracting (97.6%)

Pulling dask ... downloading (48.4%)

Pulling dask ... extracting (99.6%)

Pulling dask ... extracting (100.0%)

Pulling dask ... downloading (51.8%)

Pulling dask ... downloading (54.8%)

Pulling dask ... pull complete

Pulling dask ... downloading (56.4%)

Pulling dask ... extracting (0.7%)

Pulling dask ... downloading (59.9%)

Pulling dask ... extracting (3.9%)

Pulling dask ... downloading (63.0%)

Pulling dask ... extracting (7.9%)

Pulling dask ... downloading (6[2021-09-13T09:56:47.188600]6.4%)

Pulling dask ... extracting (10.5%)

Pulling dask ... downloading (70.7%)

Pulling dask ... extracting (15.8%)

Pulling dask ... extracting (20.4%)

Pulling dask ... downloading (72.6%)

Pulling dask ... extracting (23.0%)

Pulling dask ... downloading (73.5%)

Pulling dask ... extracting (24.4%)

Pulling dask ... downloading (74.4%)

Pulling dask ... downloading (75.6%)

Pulling dask ... extracting (25.7%)

Pulling dask ... downloading (76.9%)

Pulling dask ... extracting (27.0%)

Pulling dask ... downloading (78.0%)

Pulling dask ... extracting (29.0%)

Pulling dask ... downloading (81.5%)

Pulling dask ... downloading (85.6%)

Pulling dask ... downloading (88.5%)

Pulling dask ... extracting (30.9%)

Pulling dask ... downloading (90.5%[2021-09-13T09:56:47.188627])

Pulling dask ... extracting (31.6%)

Pulling dask ... downloading (93.0%)

Pulling dask ... downloading (94.9%)

Pulling dask ... extracting (32.9%)

Pulling dask ... downloading (96.3%)

Pulling dask ... extracting (33.6%)

Pulling dask ... downloading (99.8%)

Pulling dask ... verifying checksum

Pulling dask ... download complete

Pulling dask ... extracting (35.5%)

Pulling dask ... extracting (44.1%)

Pulling dask ... extracting (47.4%)

Pulling dask ... extracting (50.7%)

Pulling dask ... extracting (52.7%)

Pulling dask ... extracting (56.0%)

Pulling dask ... extracting (59.9%)

Pulling dask ... extracting (63.8%)

Pulling dask ... extracting (66.5%)

Pulling dask ... extracting (67.8%)

Pulling dask ... extracting (70.4%)
[[2021-09-13T09:56:47.188682]2K
Pulling dask ... extracting (72.4%)

Pulling dask ... extracting (73.1%)

Pulling dask ... extracting (75.7%)

Pulling dask ... extracting (78.3%)

Pulling dask ... extracting (80.3%)

Pulling dask ... extracting (82.3%)

Pulling dask ... extracting (87.5%)

Pulling dask ... extracting (93.5%)

Pulling dask ... extracting (100.0%)

Pulling dask ... pull complete

Pulling dask ... extracting (1.0%)

Pulling dask ... extracting (6.1%)

Pulling dask ... extracting (9.1%)

Pulling dask ... extracting (14.1%)

Pulling dask ... extracting (15.1%)

Pulling dask ... extracting (20.2%)

Pulling dask ... extracting (24.2%)

Pulling dask ... extracting (29.2%)

Pulling dask ... extracting (35.3%)

Pulling dask ... extracting (39.3%)

Pulling dask ... ex[2021-09-13T09:56:47.188710]tracting (42.4%)

Pulling dask ... extracting (50.4%)

Pulling dask ... extracting (52.4%)

Pulling dask ... extracting (53.4%)

Pulling dask ... extracting (55.5%)

Pulling dask ... extracting (57.5%)

Pulling dask ... extracting (62.5%)

Pulling dask ... extracting (64.5%)

Pulling dask ... extracting (69.6%)

Pulling dask ... extracting (73.6%)

Pulling dask ... extracting (74.6%)

Pulling dask ... extracting (78.7%)

Pulling dask ... extracting (79.7%)

Pulling dask ... extracting (82.7%)

Pulling dask ... extracting (83.7%)

Pulling dask ... extracting (85.7%)

Pulling dask ... extracting (87.7%)

Pulling dask ... extracting (88.7%)

Pulling dask ... extracting (90.8%)

Pulling dask ... extracting (92.8%)

Pulling dask ... extracting (94.8%[2021-09-13T09:56:47.188737])

Pulling dask ... extracting (96.8%)

Pulling dask ... extracting (97.8%)

Pulling dask ... extracting (99.8%)

Pulling dask ... extracting (100.0%)

Pulling dask ... pull complete

Pulling dask ... extracting (0.9%)

Pulling dask ... extracting (9.5%)

Pulling dask ... extracting (15.5%)

Pulling dask ... extracting (17.3%)

Pulling dask ... extracting (19.0%)

Pulling dask ... extracting (21.6%)

Pulling dask ... extracting (27.6%)

Pulling dask ... extracting (32.8%)

Pulling dask ... extracting (37.1%)

Pulling dask ... extracting (42.3%)

Pulling dask ... extracting (48.3%)

Pulling dask ... extracting (53.5%)

Pulling dask ... extracting (57.8%)

Pulling dask ... extracting (63.9%)

Pulling dask ... extracting (71.6%)

Pullin[2021-09-13T09:56:47.188763]g dask ... extracting (82.0%)

Pulling dask ... extracting (87.2%)

Pulling dask ... extracting (95.0%)

Pulling dask ... extracting (99.3%)

Pulling dask ... extracting (100.0%)

Pulling dask ... pull complete

Pulling dask ... extracting (100.0%)

Pulling dask ... extracting (100.0%)

Pulling dask ... pull complete

Pulling dask ... extracting (0.2%)

Pulling dask ... extracting (1.5%)

Pulling dask ... extracting (3.1%)

Pulling dask ... extracting (3.8%)

Pulling dask ... extracting (4.1%)

Pulling dask ... extracting (4.3%)

Pulling dask ... extracting (4.4%)

Pulling dask ... extracting (4.7%)

Pulling dask ... extracting (5.1%)

Pulling dask ... extracting (5.2%)

Pulling dask ... extracting (5.5%)

Pulling dask ... extracting (5.8%)
[2021-09-13T09:56:47.188797]
Pulling dask ... extracting (6.0%)

Pulling dask ... extracting (6.3%)

Pulling dask ... extracting (6.7%)

Pulling dask ... extracting (6.9%)

Pulling dask ... extracting (7.0%)

Pulling dask ... extracting (7.2%)

Pulling dask ... extracting (7.5%)

Pulling dask ... extracting (7.7%)

Pulling dask ... extracting (7.8%)

Pulling dask ... extracting (8.0%)

Pulling dask ... extracting (8.3%)

Pulling dask ... extracting (8.4%)

Pulling dask ... extracting (8.7%)

Pulling dask ... extracting (9.2%)

Pulling dask ... extracting (9.5%)

Pulling dask ... extracting (10.6%)

Pulling dask ... extracting (11.6%)

Pulling dask ... extracting (12.7%)

Pulling dask ... extracting (13.3%)

Pulling dask ... extracting (14.5%)

Pulling dask ... extr[2021-09-13T09:56:47.288603]acting (15.9%)

Pulling dask ... extracting (16.5%)

Pulling dask ... extracting (17.0%)

Pulling dask ... extracting (17.6%)

Pulling dask ... extracting (18.1%)

Pulling dask ... extracting (18.8%)

Pulling dask ... extracting (20.2%)

Pulling dask ... extracting (21.6%)

Pulling dask ... extracting (22.7%)

Pulling dask ... extracting (23.9%)

Pulling dask ... extracting (24.8%)

Pulling dask ... extracting (25.1%)

Pulling dask ... extracting (26.3%)

Pulling dask ... extracting (27.9%)

Pulling dask ... extracting (29.1%)

Pulling dask ... extracting (30.5%)

Pulling dask ... extracting (32.0%)

Pulling dask ... extracting (34.0%)

Pulling dask ... extracting (36.1%)

Pulling dask ... extracting (37.7%)

Pulling dask ... extracting (38.9%)
[2021-09-13T09:56:47.288631]
Pulling dask ... extracting (39.7%)

Pulling dask ... extracting (40.4%)

Pulling dask ... extracting (42.1%)

Pulling dask ... extracting (43.3%)

Pulling dask ... extracting (44.7%)

Pulling dask ... extracting (45.2%)

Pulling dask ... extracting (45.8%)

Pulling dask ... extracting (46.5%)

Pulling dask ... extracting (47.0%)

Pulling dask ... extracting (47.8%)

Pulling dask ... extracting (48.4%)

Pulling dask ... extracting (48.8%)

Pulling dask ... extracting (49.6%)

Pulling dask ... extracting (50.2%)

Pulling dask ... extracting (51.0%)

Pulling dask ... extracting (51.7%)

Pulling dask ... extracting (52.2%)

Pulling dask ... extracting (52.5%)

Pulling dask ... extracting (52.7%)

Pulling dask ... extracting (53.6%)

Pu[2021-09-13T09:56:47.288671]lling dask ... extracting (53.7%)

Pulling dask ... extracting (54.4%)

Pulling dask ... extracting (55.0%)

Pulling dask ... extracting (55.3%)

Pulling dask ... extracting (55.6%)

Pulling dask ... extracting (55.9%)

Pulling dask ... extracting (56.0%)

Pulling dask ... extracting (56.5%)

Pulling dask ... extracting (56.8%)

Pulling dask ... extracting (57.3%)

Pulling dask ... extracting (57.7%)

Pulling dask ... extracting (58.2%)

Pulling dask ... extracting (58.8%)

Pulling dask ... extracting (59.3%)

Pulling dask ... extracting (59.6%)

Pulling dask ... extracting (59.9%)

Pulling dask ... extracting (60.5%)

Pulling dask ... extracting (60.9%)

Pulling dask ... extracting (61.5%)

Pulling dask ... extracting (61.9%)

Pulling dask ... [2021-09-13T09:56:47.288706]extracting (62.5%)

Pulling dask ... extracting (62.6%)

Pulling dask ... extracting (62.8%)

Pulling dask ... extracting (63.1%)

Pulling dask ... extracting (63.4%)

Pulling dask ... extracting (63.7%)

Pulling dask ... extracting (64.2%)

Pulling dask ... extracting (64.5%)

Pulling dask ... extracting (64.9%)

Pulling dask ... extracting (65.5%)

Pulling dask ... extracting (66.1%)

Pulling dask ... extracting (66.8%)

Pulling dask ... extracting (67.4%)

Pulling dask ... extracting (68.0%)

Pulling dask ... extracting (68.4%)

Pulling dask ... extracting (68.6%)

Pulling dask ... extracting (68.9%)

Pulling dask ... extracting (69.1%)

Pulling dask ... extracting (69.5%)

Pulling dask ... extracting (70.7%)

Pulling dask ... extracting (71.[2021-09-13T09:56:47.288734]2%)

Pulling dask ... extracting (71.5%)

Pulling dask ... extracting (72.3%)

Pulling dask ... extracting (72.6%)

Pulling dask ... extracting (73.5%)

Pulling dask ... extracting (74.1%)

Pulling dask ... extracting (74.6%)

Pulling dask ... extracting (75.2%)

Pulling dask ... extracting (76.2%)

Pulling dask ... extracting (77.0%)

Pulling dask ... extracting (77.9%)

Pulling dask ... extracting (79.3%)

Pulling dask ... extracting (80.2%)

Pulling dask ... extracting (80.8%)

Pulling dask ... extracting (81.5%)

Pulling dask ... extracting (81.9%)

Pulling dask ... extracting (82.4%)

Pulling dask ... extracting (83.0%)

Pulling dask ... extracting (83.4%)

Pulling dask ... extracting (84.5%)

Pulling dask ... extracting (85.1%)
[2[2021-09-13T09:56:47.388785]K
Pulling dask ... extracting (85.3%)

Pulling dask ... extracting (85.9%)

Pulling dask ... extracting (86.5%)

Pulling dask ... extracting (87.3%)

Pulling dask ... extracting (88.0%)

Pulling dask ... extracting (88.6%)

Pulling dask ... extracting (89.6%)

Pulling dask ... extracting (90.2%)

Pulling dask ... extracting (90.3%)

Pulling dask ... extracting (91.9%)

Pulling dask ... extracting (92.5%)

Pulling dask ... extracting (92.6%)

Pulling dask ... extracting (92.8%)

Pulling dask ... extracting (92.9%)

Pulling dask ... extracting (93.2%)

Pulling dask ... extracting (93.5%)

Pulling dask ... extracting (93.7%)

Pulling dask ... extracting (94.3%)

Pulling dask ... extracting (94.6%)

Pulling dask ... extracting (94.8%)

Pulling dask [2021-09-13T09:56:47.388812]... extracting (95.2%)

Pulling dask ... extracting (95.8%)

Pulling dask ... extracting (96.0%)

Pulling dask ... extracting (97.5%)

Pulling dask ... extracting (98.9%)

Pulling dask ... extracting (99.2%)

Pulling dask ... extracting (100.0%)

Pulling dask ... extracting (100.0%)

Pulling dask ... pull complete

Pulling dask ... digest: sha256:0f782908987674ea1e...

Pulling dask ... status: downloaded newer image fo...

Pulling dask ... done
Token ****
[   65.735490] cloud-init[982]: Data:
[   65.735699] cloud-init[982]:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[   65.736004] cloud-init[982]:                                  Dload  Upload   Total   Spent    Left  Speed
[   65.747693] cloud-init[982]:
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <IP_ADDRESS>:443...
[   65.747797] cloud-init[982]: * TCP_NODELAY set
[   65.760098] cloud-init[982]: * Connected to cloud.coiled.io (<IP_ADDRESS>) port 443 (#0)
[   65.762673] cloud-init[982]: * ALPN, offering h2
[   65.762745] cloud-init[982]: * ALPN, offering http/1.1
[   65.766666] cloud-init[982]: * successfully set certificate verify locations:
[   65.766734] cloud-init[982]: *   CAfile: /etc/ssl/certs/ca-certificates.crt
[   65.766771] cloud-init[982]:   CApath: /etc/ssl/certs
[   65.767653] cloud-init[982]: } [5 bytes data]
[   65.768004] cloud-init[982]: * TLSv1.3 (OUT), TLS handshake, Client hello (1):
[   65.768668] cloud-init[982]: } [512 bytes data]
[   65.781103] cloud-init[982]: * TLSv1.3 (IN), TLS handshake, Server hello (2):
[   65.783387] cloud-init[982]: { [98 bytes data]
[   65.784522] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Certificate (11):
[   65.786355] cloud-init[982]: { [4934 bytes data]
[   65.787505] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
[   65.789345] cloud-init[982]: { [333 bytes data]
[   65.790396] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Server finished (14):
[   65.792043] cloud-init[982]: { [4 bytes data]
[   65.793068] cloud-init[982]: * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
[   65.794992] cloud-init[982]: } [70 bytes data]
[   65.796527] cloud-init[982]: * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
[   65.798451] cloud-init[982]: } [1 bytes data]
[   65.799539] cloud-init[982]: * TLSv1.2 (OUT), TLS handshake, Finished (20):
[   65.801172] cloud-init[982]: } [16 bytes data]
[   65.802322] cloud-init[982]: * TLSv1.2 (IN), TLS handshake, Finished (20):
[   65.803935] cloud-init[982]: { [16 bytes data]
[   65.804959] cloud-init[982]: * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
[   65.806951] cloud-init[982]: * ALPN, server accepted to use h2
[   65.808411] cloud-init[982]: * Server certificate:
[   65.809573] cloud-init[982]: *  subject: CN=cloud.coiled.io
[   65.810864] cloud-init[982]: *  start date: Aug 22 00:00:00 2021 GMT
[   65.812304] cloud-init[982]: *  expire date: Sep 20 23:59:59 2022 GMT
[   65.813842] cloud-init[982]: *  subjectAltName: host "cloud.coiled.io" matched cert's "cloud.coiled.io"
[   65.816033] cloud-init[982]: *  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
[   65.817847] cloud-init[982]: *  SSL certificate verify ok.
[   65.819196] cloud-init[982]: * Using HTTP2, server supports multi-use
[   65.820748] cloud-init[982]: * Connection state changed (HTTP/2 confirmed)
[   65.822256] cloud-init[982]: * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
[   65.824570] cloud-init[982]: } [5 bytes data]
[   65.825687] cloud-init[982]: * Using Stream ID: 1 (easy handle 0x5576ca1f6d50)
[   65.827372] cloud-init[982]: } [5 bytes data]
[   65.828535] cloud-init[982]: > POST /api/v1/rrpelgrim/notifications/ HTTP/2
[   65.830209] cloud-init[982]: > Host: cloud.coiled.io
[   65.831389] cloud-init[982]: > user-agent: curl/7.68.0
[   65.832597] cloud-init[982]: > accept: */*
[   65.833638] cloud-init[982]: > content-type: application/json
[   65.835083] cloud-init[982]: > authorization: Token ****
[   65.837178] cloud-init[982]: > content-length: 389
[   65.838373] cloud-init[982]: >
[   65.839204] cloud-init[982]: { [5 bytes data]
[   65.840513] cloud-init[982]: * Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
[   65.843001] cloud-init[982]: } [5 bytes data]
[   65.844609] cloud-init[982]: * We are completely uploaded and fine
[   65.846894] cloud-init[982]: { [5 bytes data]
[   65.848531] cloud-init[982]: < HTTP/2 200
[   65.850044] cloud-init[982]: < date: Mon, 13 Sep 2021 09:56:47 GMT
[   65.852061] cloud-init[982]: < content-type: application/json
[   65.853864] cloud-init[982]: < content-length: 464
[   65.855548] cloud-init[982]: < server: uvicorn
[   65.857044] cloud-init[982]: < vary: Accept, Origin
[   65.858586] cloud-init[982]: < allow: GET, POST, HEAD, OPTIONS
[   65.860593] cloud-init[982]: < x-frame-options: DENY
[   65.862334] cloud-init[982]: < x-content-type-options: nosniff
[   65.864336] cloud-init[982]: < referrer-policy: same-origin
[   65.866130] cloud-init[982]: <
[   65.867307] cloud-init[982]: { [464 bytes data]
[   65.868892] cloud-init[982]:
100   853  100   464  100   389   1198   1005 --:--:-- --:--:-- --:--:--  2204
[   65.872192] cloud-init[982]: * Connection #0 to host cloud.coiled.io left intact
[   65.874528] cloud-init[982]: {"msg":"coiled-dask-rrpelgr71-44751-worker: Successfully pulled docker image:<PHONE_NUMBER>81.dkr.ecr.us-east-1.amazonaws.com/prod/coiled-examples-prefect:13f0a3f8-5084-4cd8-8a1c-44f4cc185b6a","data":{"vm_label":"coiled-dask-rrpelgr71-44751-worker"},"id":"07ca14","username":"rrpelgrim","account":"rrpelgrim","level":20,"event_type":"vm_event","logging_context":{"view.name":"django.view.POST","user.username":"rrpelgrim","user.id":1292,"user.is_authenticated":true}}COILED SERVER IS: https://cloud.coiled.io
[   66.196852] cloud-init[982]: Recreating tmp_dask_1 ...
[   72.862614] cloud-init[982]:
Recreating tmp_dask_1 ... done
Attaching to tmp_dask_1
[   72.862781] cloud-init[982]: distributed.preloading - INFO - Downloading preload at https://cloud.coiled.io/preloads/OifdkvxVFEiSEOYE2ewQF_ozbPnKWSHwQLYvLqg13DbokbOKQsdaTA/worker-name.py
[   73.046257] cloud-init[982]: distributed.preloading - INFO - Run preload setup function: https://cloud.coiled.io/preloads/OifdkvxVFEiSEOYE2ewQF_ozbPnKWSHwQLYvLqg13DbokbOKQsdaTA/worker-name.py
[   85.103021] cloud-init[982]: distributed.nanny - INFO -         Start Nanny at: 'tls://<IP_ADDRESS>:34435'
[   85.573968] cloud-init[982]: distributed.worker - INFO -       Start worker at:    tls://<IP_ADDRESS>:42563
[   85.576395] cloud-init[982]: distributed.worker - INFO -          Listening to:    tls://<IP_ADDRESS>:42563
[   85.579020] cloud-init[982]: distributed.worker - INFO -          dashboard at:          <IP_ADDRESS>:39763
[   85.579158] cloud-init[982]: distributed.worker - INFO - Waiting to connect to:      tls://<IP_ADDRESS>:8786
[   85.579420] cloud-init[982]: distributed.worker - INFO - -------------------------------------------------
[   85.579785] cloud-init[982]: distributed.worker - INFO -               Threads:                          2
[   85.580157] cloud-init[982]: distributed.worker - INFO -                Memory:                   7.48 GiB
[   85.580507] cloud-init[982]: distributed.worker - INFO -       Local Directory: /dask-worker-space/worker-a4lzf6ty
[   85.580875] cloud-init[982]: distributed.worker - INFO - -------------------------------------------------
[   85.634882] cloud-init[982]: distributed.worker - INFO -         Registered to:      tls://<IP_ADDRESS>:8786
[   85.637552] cloud-init[982]: distributed.worker - INFO - -------------------------------------------------
[   85.639679] cloud-init[982]: distributed.core - INFO - Starting established connection
[   87.372612] cloud-init[982]: distributed.worker - INFO - Starting Worker plugin coiled-aws-env
[  112.648156] cloud-init[982]: distributed.utils_perf - INFO - full garbage collection released 159.79 MiB from 538 reference cycles (threshold: 9.54 MiB)
[  134.702884] cloud-init[982]: distributed.utils_perf - INFO - full garbage collection released 79.54 MiB from 874 reference cycles (threshold: 9.54 MiB)
[  145.779991] cloud-init[982]: distributed.nanny - INFO - Worker process 17 was killed by signal 11
[  145.807014] cloud-init[982]: distributed.nanny - WARNING - Restarting worker
[  146.267877] cloud-init[982]: distributed.worker - INFO -       Start worker at:    tls://<IP_ADDRESS>:45761
[  146.268035] cloud-init[982]: distributed.worker - INFO -          Listening to:    tls://<IP_ADDRESS>:45761
[  146.268378] cloud-init[982]: distributed.worker - INFO -          dashboard at:          <IP_ADDRESS>:41215
[  146.268657] cloud-init[982]: distributed.worker - INFO - Waiting to connect to:      tls://<IP_ADDRESS>:8786
[  146.268984] cloud-init[982]: distributed.worker - INFO - -------------------------------------------------
[  146.269311] cloud-init[982]: distributed.worker - INFO -               Threads:                          2
[  146.280339] cloud-init[982]: distributed.worker - INFO -                Memory:                   7.48 GiB
[  146.282723] cloud-init[982]: distributed.worker - INFO -       Local Directory: /dask-worker-space/worker-syptp257
[  146.285832] cloud-init[982]: distributed.worker - INFO - -------------------------------------------------
[  146.300347] cloud-init[982]: distributed.worker - INFO - Starting Worker plugin coiled-aws-env
[  146.302840] cloud-init[982]: distributed.worker - INFO -         Registered to:      tls://<IP_ADDRESS>:8786
[  146.304910] cloud-init[982]: distributed.worker - INFO - -------------------------------------------------
[  146.307064] cloud-init[982]: distributed.core - INFO - Starting established connection
[  154.865998] cloud-init[982]: distributed.utils_perf - INFO - full garbage collection released 51.05 MiB from 126 reference cycles (threshold: 9.54 MiB)

cc @jorisvandenbossche I looked a bit into this and it turns out to be a segmenetation fault on pyarrow side. I couldn't find out more, yet, but if you have a suggestion on how to debug this, that's much appreciated.

Hmm, with the current information that's difficult to say. Were you able to observe in what functionality the segmentation fault happened? (is it from writing the parquet file, or from converting to arrow, ..?)
My first suggestion would be to use a debug build of arrow which can give more information when crashing (for this you will probably have to build Arrow from source, AFAIK)
Some other non-arrow-specific suggestions/questions: do you see it starting with a certain size? (the workers certainly have enough memory?) Do you see it for a specific dtype? (there are both timestamp, int, string and float columns in the timeseries dataset) Does it matter if writing statistics or not?

Update:
I made the rookie 'mistake' of switching a few things out in the cluster's software environments mid-debugging without noting down details of the s-env I started with.
I am now not able to reproduce my own issue above. I'm running pyarrow 5.0.0 instead of 4.0.1. Writing the same 375GB dataset to S3 as Parquet is working fine. Even up 1.4TB works.
Good thing is it seems my problem is solved :) unfortunately I'm not entirely sure why...

@ncclementi - no, the cluster and client were both still running.

Seeing as @rrpelgrim was no longer able to reproduce the error after changing software environments, I suggest we close this issue. There are certainly things to tackle when it comes to processing large parquet datasets, but I think we can continue those discussions in the specific issues tracked by the meta-issue #8031


How to delay in the circular animation?

Hello, great repo thank you for the nice work.
One query, how we could add a little delay in circular animation on the component load?

Hi @Taimoormk!
If you just want a fixed delay, you could wrap the progressbar in another component which has a setTimeout call in componentDidMount which sets the percentage prop from 0 to the desired percentage after a timeout, which would achieve what you want.
If you want to delay the animation until the component is visible, see this thread: https://github.com/iqnivek/react-circular-progressbar/issues/64. It has an example codesandbox which implements the visibility detection: https://codesandbox.io/s/81wzmm8n00
Does this address your question?

It sure does, thank you for a detailed explanation and the sample code.
Cheers


Migrate to GitHub Actions

At the moment building and testing the code is done with travis. Since the free account now comes with a finite amount of testing budget the quality check should be moved to GitHub Actions.
This repository will be the first test of the general migration.

Done with #8.


Turn on pack for binding examples and smiles ligands

I just noticed that in our binding examples with ligands generated from smiles the pack option is off. I’ll open a PR to fix it.

Ah! Sorry, the option was already on. It was just the yank docs reported the incorrect default.

Is it really on by default? The CK2 example had the ligand start far away.

It is off by default, but the docs reported it on. I just didn't see the pack option specified the first time I looked at the example YAML script.

Ah! Thanks!

So we should definitely turn that on in the examples that use Harmonic or FlatBottom restraints.


Several improvements for the Tilemap editor

I'm working on some improvements in the built-in Tilemap editor, based on some issues, mainly #843:

[x] Rectangular drawing and erasing.
Ctrl+Shift+L_DRAG: Draw.
Ctrl+Shift+R_DRAG: Erase.
[x] Line drawing and erasing.
Uses the Bresenham's line algorithm.
Shift+L_DRAG: Draw.
Shift+R_DRAG: Erase.
Brush size.
[x] Bucket fill.
It uses a Flood Fill algorithm, and uses the node rect as limit.
Missing shortcut
[x] Search by name on the palette.
Ctrl+F: Will focus the search box if the 2D editor has the focus.
Zoom for the tile palette.
[x] Tilemap menu in the 2D editor toolbar.

And i made some small additions and changes:

Shift+B for box select.
Duplicate preview.
When duplicating the original selection is preserved.
Removed list display.

Suggestions are welcome.

I'll not be able to finish all features now, but i'll try later. This pr is basically finished, it only needs testing, especially for changing some last things.

It looks really cool, I'll try to test it tonight or tomorrow morning.

How about putting a horizontal separator between the TileMap tools menu and the rest of the menu on the left? Right now it's quite confusing to have all the usual 2D Viewport tools available but not working (select mode, move mode, rotate mode, pan mode, etc.).
In the future it might be nice to hide them when in the TileMap editor plugin (and reuse some of their icons for TileMap specific features like the ones you are adding).

Thanks, i'll work on those issues when i get home.

About the horizontal space, i had this idea, put a space between the TileMap tools and the rest of menu:

Or with a simple separator:

Putting a space and having the tilemap tools right aligned sounds good :)

Fixed some small inconsistencies, and the toolbar is now right aligned.

Suggestions:

Select tiles/rect with the mouse and move / copy it, like Tiled does
Middle click to pick a placed tile instead of having to find it in the tile list
Ability to define neighboring rules?
Shortcuts to flip / rotate tiles, individually or the whole selection


runtime: go build -gcflags "all=-N -l"  runtime.inHeapOrStack: nosplit stack overflow

What version of Go are you using (go version)?

$ go version
go version go1.14.3 linux/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
The faulty operating system is the latest version of ubuntu 20.04 (2020-05-30), ubuntu 18.04 does not have this problem
go env Output
ubuntu:~$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/aaa/.cache/go-build"
GOENV="/home/aaa/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/aaa/go"
GOPRIVATE=""
GOPROXY="https://goproxy.io"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build022333314=/tmp/go-build -gno-record-gcc-switches"

What did you do?
The faulting code is https://play.golang.org/p/eX7XVgcMFJt
This code is from the google / gvisor project example
https://github.com/google/gvisor/blob/master/pkg/tcpip/sample/tun_tcp_echo/main.go
Need to use this command to get dependent libraries
 go get gvisor.dev/gvisor/pkg/tcpip@go
Use the following command to compile
go build -gcflags "all=-N -l"
What did you expect to see?
Compiled successfully
What did you see instead?
aaa@ubuntu:~/go/src/netstack/test1/base1$ go build -gcflags "all=-N -l" /home/aaa/go/src/netstack/test1/base1/base.go
# command-line-arguments
runtime.inHeapOrStack: nosplit stack overflow
        760     assumed on entry to gvisor.dev/gvisor/pkg/abi/linux.(*Statx).CopyOut (nosplit)
        632     after gvisor.dev/gvisor/pkg/abi/linux.(*Statx).CopyOut (nosplit) uses 128
        624     on entry to gvisor.dev/gvisor/pkg/abi/linux.(*Statx).CopyOutN (nosplit)
        336     after gvisor.dev/gvisor/pkg/abi/linux.(*Statx).CopyOutN (nosplit) uses 288
        328     on entry to runtime.gcWriteBarrier (nosplit)
        200     after runtime.gcWriteBarrier (nosplit) uses 128
        192     on entry to runtime.wbBufFlush (nosplit)
        152     after runtime.wbBufFlush (nosplit) uses 40
        144     on entry to runtime.cgoCheckWriteBarrier (nosplit)
        96      after runtime.cgoCheckWriteBarrier (nosplit) uses 48
        88      on entry to runtime.cgoIsGoPointer (nosplit)
        16      after runtime.cgoIsGoPointer (nosplit) uses 72
        8       on entry to runtime.inHeapOrStack (nosplit)
        -24     after runtime.inHeapOrStack (nosplit) uses 32
runtime.morestack: nosplit stack overflow
        760     assumed on entry to gvisor.dev/gvisor/pkg/abi/linux.(*Timespec).CopyOut (nosplit)
        632     after gvisor.dev/gvisor/pkg/abi/linux.(*Timespec).CopyOut (nosplit) uses 128
        624     on entry to gvisor.dev/gvisor/pkg/abi/linux.(*Timespec).CopyOutN (nosplit)
        424     after gvisor.dev/gvisor/pkg/abi/linux.(*Timespec).CopyOutN (nosplit) uses 200
        416     on entry to runtime.gcWriteBarrier (nosplit)
        288     after runtime.gcWriteBarrier (nosplit) uses 128
        280     on entry to runtime.wbBufFlush (nosplit)
        240     after runtime.wbBufFlush (nosplit) uses 40
        232     on entry to runtime.cgoCheckWriteBarrier (nosplit)
        184     after runtime.cgoCheckWriteBarrier (nosplit) uses 48
        176     on entry to runtime.cgoIsGoPointer (nosplit)
        104     after runtime.cgoIsGoPointer (nosplit) uses 72
        96      on entry to runtime.inHeapOrStack (nosplit)
        64      after runtime.inHeapOrStack (nosplit) uses 32
        56      on entry to runtime.spanOf (nosplit)
        16      after runtime.spanOf (nosplit) uses 40
        8       on entry to runtime.panicIndexU (nosplit)
        0       on entry to runtime.goPanicIndexU
        -8      on entry to runtime.morestack (nosplit)
runtime.morestack: nosplit stack overflow
        760     assumed on entry to gvisor.dev/gvisor/pkg/abi/linux.(*StatxTimestamp).CopyOut (nosplit)
        632     after gvisor.dev/gvisor/pkg/abi/linux.(*StatxTimestamp).CopyOut (nosplit) uses 128
        624     on entry to gvisor.dev/gvisor/pkg/abi/linux.(*StatxTimestamp).CopyOutN (nosplit)
        424     after gvisor.dev/gvisor/pkg/abi/linux.(*StatxTimestamp).CopyOutN (nosplit) uses 200
        416     on entry to runtime.gcWriteBarrier (nosplit)
        288     after runtime.gcWriteBarrier (nosplit) uses 128
        280     on entry to runtime.wbBufFlush (nosplit)
        240     after runtime.wbBufFlush (nosplit) uses 40
        232     on entry to runtime.cgoCheckWriteBarrier (nosplit)
        184     after runtime.cgoCheckWriteBarrier (nosplit) uses 48
        176     on entry to runtime.cgoIsGoPointer (nosplit)
        104     after runtime.cgoIsGoPointer (nosplit) uses 72
        96      on entry to runtime.inHeapOrStack (nosplit)
        64      after runtime.inHeapOrStack (nosplit) uses 32
        56      on entry to runtime.spanOf (nosplit)
        16      after runtime.spanOf (nosplit) uses 40
        8       on entry to runtime.panicIndexU (nosplit)
        0       on entry to runtime.goPanicIndexU
        -8      on entry to runtime.morestack (nosplit)
runtime.morestack: nosplit stack overflow
        760     assumed on entry to gvisor.dev/gvisor/pkg/abi/linux.(*EpollEvent).CopyOut (nosplit)
        632     after gvisor.dev/gvisor/pkg/abi/linux.(*EpollEvent).CopyOut (nosplit) uses 128
        624     on entry to gvisor.dev/gvisor/pkg/abi/linux.(*EpollEvent).CopyOutN (nosplit)
        424     after gvisor.dev/gvisor/pkg/abi/linux.(*EpollEvent).CopyOutN (nosplit) uses 200
        416     on entry to runtime.gcWriteBarrier (nosplit)
        288     after runtime.gcWriteBarrier (nosplit) uses 128
        280     on entry to runtime.wbBufFlush (nosplit)
        240     after runtime.wbBufFlush (nosplit) uses 40
        232     on entry to runtime.cgoCheckWriteBarrier (nosplit)
        184     after runtime.cgoCheckWriteBarrier (nosplit) uses 48
        176     on entry to runtime.cgoIsGoPointer (nosplit)
        104     after runtime.cgoIsGoPointer (nosplit) uses 72
        96      on entry to runtime.inHeapOrStack (nosplit)
        64      after runtime.inHeapOrStack (nosplit) uses 32
        56      on entry to runtime.spanOf (nosplit)
        16      after runtime.spanOf (nosplit) uses 40
        8       on entry to runtime.panicIndexU (nosplit)
        0       on entry to runtime.goPanicIndexU
        -8      on entry to runtime.morestack (nosplit)
runtime.inHeapOrStack: nosplit stack overflow
        760     assumed on entry to gvisor.dev/gvisor/pkg/abi/linux.(*Stat).CopyOut (nosplit)
        632     after gvisor.dev/gvisor/pkg/abi/linux.(*Stat).CopyOut (nosplit) uses 128
        624     on entry to gvisor.dev/gvisor/pkg/abi/linux.(*Stat).CopyOutN (nosplit)
        344     after gvisor.dev/gvisor/pkg/abi/linux.(*Stat).CopyOutN (nosplit) uses 280
        336     on entry to runtime.gcWriteBarrier (nosplit)
        208     after runtime.gcWriteBarrier (nosplit) uses 128
        200     on entry to runtime.wbBufFlush (nosplit)
        160     after runtime.wbBufFlush (nosplit) uses 40
        152     on entry to runtime.cgoCheckWriteBarrier (nosplit)
        104     after runtime.cgoCheckWriteBarrier (nosplit) uses 48
        96      on entry to runtime.cgoIsGoPointer (nosplit)
        24      after runtime.cgoIsGoPointer (nosplit) uses 72
        16      on entry to runtime.inHeapOrStack (nosplit)
        -16     after runtime.inHeapOrStack (nosplit) uses 32
runtime.morestack: nosplit stack overflow
        760     assumed on entry to gvisor.dev/gvisor/pkg/abi/linux.(*PtraceRegs).CopyOut (nosplit)
        632     after gvisor.dev/gvisor/pkg/abi/linux.(*PtraceRegs).CopyOut (nosplit) uses 128
        624     on entry to gvisor.dev/gvisor/pkg/abi/linux.(*PtraceRegs).CopyOutN (nosplit)
        424     after gvisor.dev/gvisor/pkg/abi/linux.(*PtraceRegs).CopyOutN (nosplit) uses 200
        416     on entry to runtime.gcWriteBarrier (nosplit)
        288     after runtime.gcWriteBarrier (nosplit) uses 128
        280     on entry to runtime.wbBufFlush (nosplit)
        240     after runtime.wbBufFlush (nosplit) uses 40
        232     on entry to runtime.cgoCheckWriteBarrier (nosplit)
        184     after runtime.cgoCheckWriteBarrier (nosplit) uses 48
        176     on entry to runtime.cgoIsGoPointer (nosplit)
        104     after runtime.cgoIsGoPointer (nosplit) uses 72
        96      on entry to runtime.inHeapOrStack (nosplit)
        64      after runtime.inHeapOrStack (nosplit) uses 32
        56      on entry to runtime.spanOf (nosplit)
        16      after runtime.spanOf (nosplit) uses 40
        8       on entry to runtime.panicIndexU (nosplit)
        0       on entry to runtime.goPanicIndexU
        -8      on entry to runtime.morestack (nosplit)

I don't think there is much that we can do here.  The failure is occurring because some code in gvisor.dev/gvisor/pkg/abi/linux is marked nosplit.  I guess that is working for normal compilation, but when you disable optimizations and inlining the code takes up too much stack space.
The only fix for this is for the nosplit code to use less stack space when not optimizing.  It looks like the biggest culprit is
gvisor.dev/gvisor/pkg/abi/linux.(*Statx).CopyOutN (nosplit) uses 288

In order for this to work that function, and perhaps others, will need to be simplified.  Or not marked as nosplit, but presumably there is a good reason for it to be nosplit.  But that function is not part of the Go project, so there isn't anything that the Go project can do about it.
So I'm going to close this issue since I don't see any action that we can take.  Please comment if you disagree.


Built in update option to the main desktop menu.

Is it possible to have an update option built into the file menu on the desktop wallet?  there may be a good reason why this can't be enabled, but thought i'd ask.  maybe everyone would be more inclined to update wallets if the function was built in for example.
I read previous issues and couldn't see a similar question.
thanks
jamiec79

There you go:
https://github.com/ArkEcosystem/ark-desktop/pull/118

nice, thank you.


TryFi Integration Not Loading Any Devices or Entities

I have the Fi 2.0 dog collar. When I installed TryFi a couple months ago, the entities never got created. I played around with pytryfi but didn't have any luck (not too experienced with GraphQL) and so this ended up on my backlog.
However I have since completely removed TryFi integration from HACS, restarted, installed latest TryFi integration in HACS, and restarted again... And then when I add the integration by entering my email and password, leaving polling at 10, the install appears successful and no errors are reported in the log.
And yet even now (48 hours later), there are still no entities or devices, despite reloading the integration and restarting HASS multiple times.
When I open my Fi app on my iPhone (iOS 14), everything looks fine. I can track my dog's location, battery, turn on/off the light, track activity, etc. So I'm at a loss as to what I'm missing.
Any ideas on what I should try next?
Thanks!

@sbabcock23 Can I ask if you're using Fi Collar 1 or 2?
Trying to figure out why I'm not getting anything back from the FetchXML requests even though properly authenticated...

Hi @sans-1 ,
I'm using the original series 1 collar. If you turn on debug are you getting any additional details?

I have series 2 and its been 48 hrs sense my integration installed with no errors and im also not seeing any entities or devices either.

@FinestDice17 can you enable debugging and share the logs related to hass-tryfi or pytryfi?

@FinestDice17 can you enable debugging and share the logs related to hass-tryfi or pytryfi?

@sbabcock23  pardon my lack of knowledge here but I do show logs under logger, is there a way to isolate just the custom component log for tryfi only? I have HA OS installed on a RPI 4 using an external NVME drive through USB. Supervisor and developer have been enabled as well.

Closing issue. User says its working.


[New Sniff] Check for removal of admin pages

Rule:
Removal of WP admin pages is not allowed.
The exception would be a child theme removing a theme admin submenu page added by the parent theme.
Ref: https://github.com/WPTRT/WordPress-Coding-Standards/issues/12#issuecomment-231783316
Theme check file covering this rule:
n/a
Decision needed:
This is currently not in the handbook as a rule. Should it be one ?
Notes for implementation:

Check for remove_menu_page() and forbid this.
Check for remove_submenu_page() and only forbid this if one of a known list of WP Core admin pages is being removed

To do:

[ ] If agreed this should be an error - Add the rule in the Theme Review handbook to the Requirements page.
[ ] If agreed this should be an error - Create unit tests
[ ] If agreed this should be an error - Create new sniff

Discussed in the meeting of May 31st, let's add this.

To create this sniff, I need some more information about the WP Core admin pages which are not supposed to be removed.
The question is basically: which submenu items are allowed to be removed ? Answers I can think of:

Only admin pages within the Themes submenu and of those, not the known core ones (themes, customizer and its variants, widgets, menus, theme-editor).
Admin pages within the Themes submenu + the Options submenu, again with the exception of the known core ones
Any admin page, as long as its not a known core one

Essentially, the only admin pages allowed to be removed would be custom Appearance submenu items created by a parent theme and removed by a child theme.  I can't think of any others we allow to be removed.  I'm not even sure that there's a child theme that does this in the directory.  The situation would be rare.

I would go with

Only admin pages within the Themes submenu and of those, not the known core ones (themes, customizer and its variants, widgets, menus, theme-editor).

I agree with Justin.

Thanks for the feedback. I have the sniff nearly ready already, but won't be able to get back to it until the weekend.

@jrfnl is this a different sniff from the forbidden functions one?

Yes it is and a lot more complicated one. Themes can removed admin pages from, for instance, a parent theme, but they are not allowed to remove WP Core admin pages, so there is a lot more involved in that.
I worked on it last it's quite tricky. I'd need to have a good look again to see where I got stuck.

I've removed the input/decision needed, as we know what is and isn't allowed.


[BUG] Cannot mount existing volume

Describe the bug
Volume fails to mount after adding a new node on the cluster, the error message is the following : 'unable to attach volume pvc-38eec084-1cf6-4725-b874-1e62b496d35a to kubernetes-node-f2705c: cannot attach volume pvc-38eec084-1cf6-4725-b874-1e62b496d35a because the data engine image longhornio/longhorn-engine:v1.6.2 is not deployed on at least one of the the replicas' nodes or the node that the volume is going to attach to'
kubernetes-node-f2705c being the new node added. In longhorn-UI all 5 nodes are all schedulable. In the engine-image-ei container on that node, I have only one log : installed
Expected behavior
I can mount the existing node
Support bundle for troubleshooting
Will be sent by email
Environment

Longhorn version: 1.6.2
Impacted volume (PV): pvc-38eec084-1cf6-4725-b874-1e62b496d35a
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Helm
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version:

Number of control plane nodes in the cluster:
Number of worker nodes in the cluster:

Node config

OS type and version:
Kernel version:
CPU per node: 4
Memory per node: 15 GB
Disk type (e.g. SSD/NVMe/HDD):
Network bandwidth between the nodes (Gbps):

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): Ovh Cloud
Number of Longhorn volumes in the cluster: 5

Additional context

Sorry, I had big issues on my cluster, everything went wrong. I had to reinstall completely Longhorn and lost all my volumes in the way...

Sorry, I had big issues on my cluster, everything went wrong. I had to reinstall completely Longhorn and lost all my volumes in the way...

Really sorry for hearing the news...
How was the issue triggered? If the replica directories still existing. You can back them up and restore the data by manual later.

I’ve made errors, I was lock with the issue above, the production environment started to fail and was not able to mount back the volume. It was installed via helm mainly because it deploys with terraform. But in the Rancher interface, the app is listed and it says it has a newer version which is the one on the rancher repo (which is false because it is the same version but bundled by rancher) and even though I have the  longhorn helm repository setup too. I thought that maybe redeploy a slightly different version will maybe reinstall and solve the issue and it did not went well at all. What I understand of the issue is that there were missing CRDs linked to longhorn and everything started to fail, the longhorn manager was logging tons of errors. I had not enough time and comprehension with the issue to start debugging the system, so I reinstalled longhorn completely. I had external backups (not with longhorn because it does not work and I still have no answer to my last message on the issue I opened a month ago), so I already restored manually all backups, I thought it would get the system up way much faster and I know the data would almost certainly be the same than my nightly backup.
I actually don’t know if I will continue with longhorn, the only time I tried to recreate a volume with a longhorn backup (on a dev environment with a setup working in that case), I got a mysterious message about corrupted backup… Nothing is decided yet because I love the product when it works, but when there is an issue, it’s a mess to understand what’s going on.
I got the serious issue (which is partly my fault) and I’m unable to setup something that works despite the massive time I’ve spent trying to understand where was the issue.


Space Dragon's Devour destroy corpses/butcher doesn't give the corpses back

Description
Whenever a Space Dragon devour a corpse and is cut open, no corpse appear
Reproduction
1-Be a space dragon
2-Eat people
3-Die
4-Butcher the dragon
5-No corpses
Screenshots

Additional context

update to this issue: people eaten by the dragon report their client freezing when the dragon is butchered. The bodies still do not appear.

Thank you for the report!
Closing this as it is a duplicate of #20405


usm: http2: Fix path used in debug print

What does this PR do?
If the path is huffman encoded, then the path is compressed (with an upper bound to compressed size of maxHTTP2Path)
thus, we need more room for the decompressed path, therefore using 2*maxHTTP2Path.

Motivation

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge


Remove use of OpenCL Image data_type from MIVisionX

We use OpenCL 1D image for LUT kernel which can be easily replaced by OpenCL buffer like we do in HIP.
This causes some failures in MI300.

@hansely I have assigned it to you.


Cannot read property "MakeAnimatedImageFromEncoded" of undefined (Expo app)

Description
I get the error message: "Cannot read property "MakeAnimatedImageFromEncoded" of undefined" when trying out a couple of different react-native graph libraries that is dependent on react-native-skia. (Eg. Victory Native)

Version
0.1.216
Steps to reproduce
Follow the installation instructions of the libs, installing the latest version of react-native-skia in a managed Expo-app. Starting up the example code.
Snack, code example, screenshot, or link to a repository
import { View } from "react-native";
import { CartesianChart, Line } from "victory-native";
export default function VictoryTest() {
return (
<View style={{ height: 300 }}>
<CartesianChart data={DATA} xKey="day" yKeys={["highTmp"]}>
{/* 👇 render function exposes various data, such as points. */}
{({ points }) => (
// 👇 and we'll use the Line component to render a line path.

)}

);
}
(The component VictoryTest is then imported into and used in App.js)

This means you are using a version of RN Skia that is not compatible with your version of Expo Go 49.
Can you confirm that my assessment is correct?
I don't think there is a bug on our side here but please let me know if that's not the case and we will reopen this.
Happy hacking!


Add release notes for v2.1.0-beta.20181008

For https://github.com/cockroachdb/cockroach/issues/30831.

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/5dfcc67d31a388eeea0703a8fb0b381b9f7da224/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/3c7a005a27a29f6c242c47c5a971f80f7e47c1ee/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/ab6cf3454ab58799fbc96d9b9a27e1f6534ab129/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/844b22922d7c7df17f735a4be79c5551934aacdd/