bug: docs - Docker node:16-alpine requires setting engineType = "binary" for Prisma to work

Provide environment information
System:
OS: Linux 6.0 Fedora Linux 37 (Workstation Edition)
CPU: (16) x64 AMD Ryzen 7 PRO 6850U with Radeon Graphics
Memory: 23.97 GB / 30.12 GB
Container: Yes
Shell: 5.9 - /bin/zsh
Binaries:
Node: 16.19.0 - ~/.volta/tools/image/node/16.19.0/bin/node
npm: 8.19.3 - ~/.volta/tools/image/node/16.19.0/bin/npm
ct3aMetadata.initVersion: 6.11.3
Describe the bug
I've added a Dockerfile (copy-pasted from the docs, using node:16-alpine as a base image) and docker-compose.yml to a freshly bootstrapped app. I modified index.tsx to run trpc.example.getAll.useQuery(), and received this error message at runtime:
Listening on port 3000 url: http://localhost:3000
prisma:error
Invalid `prisma.example.findMany()` invocation:

Unable to load Node-API Library from /app/node_modules/.prisma/client/libquery_engine-linux-musl.so.node, Library may be corrupt

I got a similar error with node:16-buster-slim (pointing to the Debian engine).
Changing the base image to node:16-buster fixes the error.
Adding engineType = "binary" to Prisma generator client also fixes the error under node:16-alpine.

To reproduce

Bootstrap application with trpc and prisma:

npm create<EMAIL_ADDRESS>

Follow steps 1-3 from the docs
Add trpc.example.getAll.useQuery() to index.tsx
Use the following minimal docker-compose.yml:

version: "3.9"
services:
  app:
    platform: "linux/amd64"
    build:
      context: .
      dockerfile: Dockerfile
      args:
        NEXT_PUBLIC_CLIENTVAR: "clientvar"
    working_dir: /app
    ports:
      - "3000:3000"
    image: t3-app
    environment:
      - DATABASE_URL=mysql://foo:password@db:3306/bar
  db:
    image: mysql:8
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    ports:
      - 3306:3306
    environment:
      MYSQL_USER: foo
      MYSQL_PASSWORD: password
      MYSQL_DATABASE: bar
      MYSQL_RANDOM_ROOT_PASSWORD: true
    volumes:
      - db:/var/lib/mysql

volumes:
  db: {}

Run docker compose up -d --build
Visit localhost:3000, then check the logs

Additional information
It's worth noting that setting engineType = "binary" is not a recommended approach according to the Prisma docs as it introduces additional overhead in the architecture: Query Engine. If there's a problem with using the Node-API Library in Alpine that seems out of scope for the t3 docs, but might be worth mentioning.

Seems like it might be related to this? https://github.com/prisma/prisma/issues/16205
Seems like it can be "fixed" by using node:16-alpine3.16 or node:18-alpine3.16 instead of the 3.17 versions. Could you confirm whether or not that works, without having to apply the engineType = "binary" setting?
If so I would recommend putting this in the docs as a temporary solution, and then keeping an eye on it as hopefully there will be a better solution soon.

@nicolomaioli hi, how can I set openssl over openssl1.1-compat ? I have tried  node:16-alpine3.16 without success

@nicolomaioli hi, how can I set openssl over openssl1.1-compat ? I have tried node:16-alpine3.16 without success

Change this line in the Dockerfile:
- RUN apk add --no-cache libc6-compat openssl1.1-compat
+ RUN apk add --no-cache libc6-compat openssl

Change this line in the Dockerfile:
- RUN apk add --no-cache libc6-compat openssl1.1-compat
+ RUN apk add --no-cache libc6-compat openssl

Edit: I believe Alpine 3.17 uses v3 of openssl, which is why you need to specify 1.1. The -compat I think has to do with the fact that Alpine uses musl rather than glibc. Hopefully this helps!

Thank you @nicolomaioli , it works! Using node:16-alpine3.16  and openssl

@c-ehrlich I'd be happy to raise a PR for the documentation if that's helpful, I haven't contributed before but it seems straightforward enough

@c-ehrlich I'd be happy to raise a PR for the documentation if that's helpful, I haven't contributed before but it seems straightforward enough

First time contributions are always welcome, especially after opening such a thorough issue.
Just so I understand correctly:

3.16 with openssl works
3.17 with openssl-compat and binary works
other combinations don't work (in particular 3.17 with openssl-compat but not setting binary)
is this correct?

If so I'm not sure what the best thing is to recommend. engineType = "binary" seems bad if Prisma recommends to avoid it. But remaining locked to 3.16 seems irresponsible as people will be opting out of security updates this way. In the long run we should probably ditch Alpine if there is no other option.
What do you (and everyone) else think is the best short-mid term solution here?

Thanks @c-ehrlich happy to take a shot at this.
Debian Buster also works without setting engineType to binary, so that might be the simplest fix and most straightforward recommendation. I need to play around with Buster slim as that would be a better replacement for Alpine.
We could add a paragraph for Alpine, and explain the trade-offs (size, performance, security), I think there’s enough to unpack there. I’m a little wary about polluting the docs though, so open to suggestions. It’s worth mentioning that Alpine 3.16 won’t reach EOL until mid-2024, so it still receives security patches. Also I would argue that the real issue there is Prisma’s lack of support for OpenSSL past v1.1.
Finally, we should consider how to best track the open issue on Prisma. Not sure what the best approach is here, maybe leaving an open issue to track?

Thanks @c-ehrlich happy to take a shot at this.
Debian Buster also works without setting engineType to binary, so that might be the simplest fix and most straightforward recommendation. I need to play around with Buster slim as that would be a better replacement for Alpine.
We could add a paragraph for Alpine, and explain the trade-offs (size, performance, security), I think there’s enough to unpack there. I’m a little wary about polluting the docs though, so open to suggestions. It’s worth mentioning that Alpine 3.16 won’t reach EOL until mid-2024, so it still receives security patches. Also I would argue that the real issue there is Prisma’s lack of support for OpenSSL past v1.1.
Finally, we should consider how to best track the open issue on Prisma. Not sure what the best approach is here, maybe leaving an open issue to track?

Sorry for the delayed reply. I think either of the following is fine:

Pin Alpine to 3.16
use engineType = "binary" (not for everyone, just as a step in the Docker instructions)
Regardless of which we choose, return to this in 6 months - hopefully Prisma has sorted it by then.

I'm leaning towards 1, but I'm far from an expert on Docker stuff so feel free to open a PR for whichever you think is the better choice :)

Thanks @c-ehrlich happy to take a shot at this.
Debian Buster also works without setting engineType to binary, so that might be the simplest fix and most straightforward recommendation. I need to play around with Buster slim as that would be a better replacement for Alpine.
We could add a paragraph for Alpine, and explain the trade-offs (size, performance, security), I think there’s enough to unpack there. I’m a little wary about polluting the docs though, so open to suggestions. It’s worth mentioning that Alpine 3.16 won’t reach EOL until mid-2024, so it still receives security patches. Also I would argue that the real issue there is Prisma’s lack of support for OpenSSL past v1.1.
Finally, we should consider how to best track the open issue on Prisma. Not sure what the best approach is here, maybe leaving an open issue to track?

Sorry for the delayed reply. I think either of the following is fine:

Pin Alpine to 3.16
use engineType = "binary" (not for everyone, just as a step in the Docker instructions)
Regardless of which we choose, return to this in 6 months - hopefully Prisma has sorted it by then.

I'm leaning towards 1, but I'm far from an expert on Docker stuff so feel free to open a PR for whichever you think is the better choice :)

No worries at all, I've also been a little swamped with the holidays!
I agree that Alpine 3.16 is the more reasonable suggestion, especially if the plan is to revise in 6 months. I'll get the PR going!

Hi, I'm one of the Prisma maintainers. I second what @nicolomaioli has stated here.
Please read this comment in a Prisma issue if you're interested in why this issue happened and how to truly solve it

@nicolomaioli Certo! Feel free to reach out again opening a new Prisma issue, although I think I know why it didn't work initially with alpine:3.17. Prisma depends on some Rust engines which are compiled for specific operating systems and/or openssl versions. As you can see in our docs, we only started supporting openssl-3.0.x for Linux Alpine starting from<EMAIL_ADDRESS>which we released right before Christmas 2022. You have probably opened this issue just a few days before that

@nicolomaioli Certo! Feel free to reach out again opening a new Prisma issue, although I think I know why it didn't work initially with alpine:3.17. Prisma depends on some Rust engines which are compiled for specific operating systems and/or openssl versions. As you can see in our docs, we only started supporting openssl-3.0.x for Linux Alpine starting from<EMAIL_ADDRESS>which we released right before Christmas 2022. You have probably opened this issue just a few days before that

That's brilliant, thank you! I'll try the different engines should be pretty straightforward. And thanks for reaching out! 🙏

@jkomyno thanks for coming in here and clarifying :)
@nicomaioli we are already on Prisma 4.8.0 now so this should hopefully be an easy fix now. If it works for you, would you be up for opening a pr for it?

@jkomyno thanks for coming in here and clarifying :)
@nicolomaioli we are already on Prisma 4.8.0 now so this should hopefully be an easy fix now. If it works for you, would you be up for opening a pr for it?

Happy to 🙌

@jkomyno @c-ehrlich I just managed to run on Alpine 3.17, with Prisma v4.8.0, using the MySQL driver. Note that my AMD laptop is currently out for repair (😢), so I'm running on a MacBook Air M1 using platform linux/amd64. This is the Dockerfile:
##### DEPENDENCIES

FROM --platform=linux/amd64 node:16-alpine3.17 AS deps
WORKDIR /app

# Install Prisma Client - remove if not using Prisma

COPY prisma ./

# Install dependencies based on the preferred package manager

COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml\* ./

RUN \
	if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
	elif [ -f package-lock.json ]; then npm ci; \
	elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i; \
	else echo "Lockfile not found." && exit 1; \
	fi

##### BUILDER

FROM --platform=linux/amd64 node:16-alpine3.17 AS builder
ARG DATABASE_URL
ARG NEXT_PUBLIC_CLIENTVAR
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# ENV NEXT_TELEMETRY_DISABLED 1

RUN \
	if [ -f yarn.lock ]; then SKIP_ENV_VALIDATION=1 yarn build; \
	elif [ -f package-lock.json ]; then SKIP_ENV_VALIDATION=1 npm run build; \
	elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && SKIP_ENV_VALIDATION=1 pnpm run build; \
	else echo "Lockfile not found." && exit 1; \
	fi

##### RUNNER

FROM --platform=linux/amd64 node:16-alpine3.17 AS runner
WORKDIR /app

ENV NODE_ENV production

# ENV NEXT_TELEMETRY_DISABLED 1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/next.config.mjs ./
COPY --from=builder /app/public ./public
COPY --from=builder /app/package.json ./package.json

COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
ENV PORT 3000

CMD ["node", "server.js"]

docker-compose.yml:
services:
  web:
    depends_on:
      - db
    build:
      context: .
      dockerfile: Dockerfile
    working_dir: /app
    ports:
      - "8080:8080"
    image: t3mysql
    environment:
      - PORT=8080
      - DATABASE_URL=mysql://test:password@db:3306/test
  db:
    image: mysql:8
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    ports:
      - 3306:3306
    environment:
      MYSQL_DATABASE: test
      MYSQL_USER: test
      MYSQL_PASSWORD: password
      MYSQL_RANDOM_ROOT_PASSWORD: true
    volumes:
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
      - db:/var/lib/mysql
volumes:
  db: {}

Note the absence of additional dependencies: no libc6-compat, and no openssl1.1-compat as the engines now support Openssl 3x and musl. Crucially, this only works in AMD64 as documented here.
I am keen to test this with PostgreSQL and SQLite also, I know very little about MongoDB tho so I could use some pointers to test this quickly.

@jkomyno @c-ehrlich I just managed to run on Alpine 3.17, with Prisma v4.8.0, using the MySQL driver. Note that my AMD laptop is currently out for repair (😢), so I'm running on a MacBook Air M1 using platform linux/amd64. This is the Dockerfile:

This seems great! I just got it running locally (M1 Pro) and can confirm it works. I benchmarked the Docker x64 emulation a while ago and the overhead was something like 5-10% depending on the task. Given how powerful the M1 is I think this is ok for now, and we don't exactly have a good alternative anyway.
Re: alpine version: I think it might be better to not pin to 3.17? What do you think?
I'm afraid I don't know much about Mongo either as I've never used it outside of toy projects, but

I would expect that adapting this setup to other databases is no different than it would be with any other Next.js app
The ratio of SQL to Mongo users of CT3A is probably something like 100:1, so I think if there is some other challenge to it, it's fine to have this become another issue once someone runs into it

A bigger issue to me is that the existing Docker setup feels like it is specifically for a production setup - multi stage build that only includes the output, not running migrations when the containers come up, etc. However people who deploy dockerized apps in my experience usually also develop in a dockerized environment, so it would be nice to enable that.
I had a working dev Docker setup a few months ago (ie optimized for being able to see changes quickly, making schema changes quickly, etc), but it was a completely separate Dockerfile and docker-compose, which afaik isn't really considered best practices anymore (?). It was extremely simple and could be improved upon but I could see if I still have the repo/branch as a starting point.

This seems great! I just got it running locally (M1 Pro) and can confirm it works. I benchmarked the Docker x64 emulation a while ago and the overhead was something like 5-10% depending on the task. Given how powerful the M1 is I think this is ok for now, and we don't exactly have a good alternative anyway.
Re: alpine version: I think it might be better to not pin to 3.17? What do you think?

That's great! Really good to hear it worked for you as well.
I think having a separate Dockerfile and docker-compose is still standard, at least in my experience with Kubernetes.
Re Alpine 3.17, I think the advantage there is that it comes with OpenSSL 3x instead of OpenSSL 1.1:
3.16
3.17
@jkomyno please correct me if I'm wrong there, be also good to get your opinion here.

This seems great! I just got it running locally (M1 Pro) and can confirm it works. I benchmarked the Docker x64 emulation a while ago and the overhead was something like 5-10% depending on the task. Given how powerful the M1 is I think this is ok for now, and we don't exactly have a good alternative anyway.

Re: alpine version: I think it might be better to not pin to 3.17? What do you think?

That's great! Really good to hear it worked for you as well.
I think having a separate Dockerfile and docker-compose is still standard, at least in my experience with Kubernetes.
Re Alpine 3.17, I think the advantage there is that it comes with OpenSSL 3x instead of OpenSSL 1.1:
3.16
3.17
@jkomyno please correct me if I'm wrong there, be also good to get your opinion here.

I definitely agree with 3.17. My question is whether we want to pin to 3.17 or not pin at all, ie use 3.18 once that is ready. My general opinion is that if a new version breaks something I'd rather know this sooner than later, but I can also see an argument for pinning to a known working version.
Also sorry for editing your post, I clicked the wrong thing and thought I was quoting it 😅 should be back to normal now

This seems great! I just got it running locally (M1 Pro) and can confirm it works. I benchmarked the Docker x64 emulation a while ago and the overhead was something like 5-10% depending on the task. Given how powerful the M1 is I think this is ok for now, and we don't exactly have a good alternative anyway.

Re: alpine version: I think it might be better to not pin to 3.17? What do you think?

That's great! Really good to hear it worked for you as well.
I think having a separate Dockerfile and docker-compose is still standard, at least in my experience with Kubernetes.
Re Alpine 3.17, I think the advantage there is that it comes with OpenSSL 3x instead of OpenSSL 1.1:
3.16
3.17
@jkomyno please correct me if I'm wrong there, be also good to get your opinion here.

I definitely agree with 3.17. My question is whether we want to pin to 3.17 or not pin at all, ie automatically use 3.18 once that is released (seems to be a ~6 month version schedule). My general opinion is that if a new version breaks something I'd rather know this sooner than later, but I can also see an argument for pinning to a known working version.
Also sorry for editing your post, I clicked the wrong thing and thought I was quoting it 😅 should be back to normal now

I have to say, I do like the way you think!
On one end, I would say that pinning the version is in line with "best practices", and that we can trust the end user to make the right call, so we don't have to come back to this every 6 months.
On the other hand, we are pinning the Node version to 16 following similar concerns, so I would say node:16-alpine3.17 makes more sense than node:16-alpine.
Another option, seeing as calling out to apk is no longer a requirement, would be to leave it completely open to the user, and our Dockerfile could look like:
ARG BASE_IMAGE

### BUILDER
FROM --platform=linux/amd64 ${BASE_IMAGE} AS deps

WORKDIR /app

# etc...

That way we are explicitly tasking the user with choosing their distribution and Node version.

This seems great! I just got it running locally (M1 Pro) and can confirm it works. I benchmarked the Docker x64 emulation a while ago and the overhead was something like 5-10% depending on the task. Given how powerful the M1 is I think this is ok for now, and we don't exactly have a good alternative anyway.

Re: alpine version: I think it might be better to not pin to 3.17? What do you think?

That's great! Really good to hear it worked for you as well.
I think having a separate Dockerfile and docker-compose is still standard, at least in my experience with Kubernetes.
Re Alpine 3.17, I think the advantage there is that it comes with OpenSSL 3x instead of OpenSSL 1.1:
3.16
3.17
@jkomyno please correct me if I'm wrong there, be also good to get your opinion here.

I definitely agree with 3.17. My question is whether we want to pin to 3.17 or not pin at all, ie automatically use 3.18 once that is released (seems to be a ~6 month version schedule). My general opinion is that if a new version breaks something I'd rather know this sooner than later, but I can also see an argument for pinning to a known working version.
Also sorry for editing your post, I clicked the wrong thing and thought I was quoting it 😅 should be back to normal now

I have to say, I do like the way you think!
On one end, I would say that pinning the version is in line with "best practices", and that we can trust the end user to make the right call, so we don't have to come back to this every 6 months.
On the other hand, we are pinning the Node version to 16 following similar concerns, so I would say node:16-alpine3.17 makes more sense than node:16-alpine.
Another option, seeing as calling out to apk is no longer a requirement, would be to leave it completely open to the user, and our Dockerfile could look like:
ARG BASE_IMAGE

### BUILDER
FROM --platform=linux/amd64 ${BASE_IMAGE} AS deps

WORKDIR /app

# etc...

That way we are explicitly tasking the user with choosing their distribution and Node version.

Sorry for the late reply, been busy + jetlagged. Thought about it and agree, pinning is fine.
I think defaulting to users providing their own base image will cause more support requests than anything else 😅
btw i can't remember if there is any particular reason why we're still on Node 16 other than the Docker docs being undermaintained

No worries! That all sounds good. I'll take Node 18 Alpine 3.17 for a spin and if everything seems to work well I'll get a PR going in the next few days.
I think last time it seemed to work well with updating the code and the English docs leaving the translations untouched, as I will be removing some of the outdated notes. Let me know if that all sounds good with you :)

No worries! That all sounds good. I'll take Node 18 Alpine 3.17 for a spin and if everything seems to work well I'll get a PR going in the next few days.
I think last time it seemed to work well with updating the code and the English docs leaving the translations untouched, as I will be removing some of the outdated notes. Let me know if that all sounds good with you :)

Sounds good :)
Btw I got a full setup working great on node 18 / alpine 3.17 including next-auth, see here:
https://github.com/t3-oss/create-t3-app/issues/992#issuecomment-1404043116
I based it on an upcoming change to the env schema validation, so maybe makes sense to get that merged before - my implementation of getting next-auth in GSSP to not crash the build by branching in the env.mjs file is a bit sloppy.
Still haven't had time to work on creating a good docker dev setup. With the setup above you can run the app non-dockerized in dev without having to change any files, but I know many projects might want their T3 app to be part of a multi-container setup because that's what they're already on, docker internal networking, etc.

I'm not sure if this is what you are looking for, but I had a setup for this back when I was deploying to Google Cloud Run (have since move to Vercel). I put together a repo here: t3-docker-compose.
This leverages extended services with two different docker-compose files so you can both:

Run with npm run dev and a mysql database in a docker compose stack;
Run a production build of the application in the same stack as the database.

Getting HMR working in docker is a bit of a faff, easiest way is probably Visual Studio Code Dev Containers. I could extend the example to support that too if it's helpful, let me know.
Also, happy to wait for the other PR to drop, let me know what you think @c-ehrlich

We are building our app with kaniko 1.9.1 and even when using Prisma 4.8.0 with gcr.io/distroless/nodejs18-debian11 we still get an error
Command failed with exit code 127: /app/packages/api/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x --enable-raw-queries cli dmmf
the-platform-api-svc-1  | /app/packages/api/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory


[Predict Protocol V2] Fix rest_predict_v2.yaml definition

What this PR does / why we need it:
The item definition of #/components/schemas/tensor_data was invalid anyOf syntax. It now correctly validates with https://apitools.dev/swagger-parser/online/
Fixes: rest_predict_v2.yaml now correctly validates

@googlebot I signed it!

/lgtm
/approve
Thanks @mfruhner !

/ok-to-test


Orgs - Edit your organization membership: "state" is an enum

endpoint scope: Organizations
endpoint name: Edit your organization membership
route: PATCH /user/memberships/orgs/:org
documentation URL: https://developer.github.com/v3/orgs/members/#edit-your-organization-membership

Current specification
https://github.com/octokit/routes/blob/a509e1a89672025ec580405648b9c5666e3e7b06/routes/orgs/members/edit-your-organization-membership.json#L13-L18
I expected

params is missing the "foo" option
{
  "name": "Edit your organization membership",
  "enabledForApps": false,
  "method": "PATCH",
  "path": "/user/memberships/orgs/:org",
  "params": [
    {
      "name": "org",
      "type": "string",
      "required": true,
      "description": ""
    },
    {
      "name": "state",
      "type": "string",
      "description": "The state that the membership should be in. Only `\"active\"` will be accepted.",
      "required": true,
      "enum": [
        "active"
      ]
    }
  ],
  "description": "",
  "documentationUrl": "https://developer.github.com/v3/orgs/members/#edit-your-organization-membership"
}

If you’d like to work on it, just comment below and follow instructions in CONTRIBUTING.md

I would like to work on this.

fixed via #105


Breaking Dependency Changes

What was wrong?
Need to upgrade the dependencies and issue a sem-versioned breaking release
How was it fixed?
Cherry-picked the correct commit, upgraded py-evm since that has the right sem version now, and upgraded towncrier. I could totes pull out the towncrier version into another PR if anyone feels strongly. I also made sure all these dependencies install in web3 v6.
To-Do:

[x] Add entry to the release notes

Cute Animal Picture

Is it still a draft? I would very much like to see this released.
Also, copying a note from a similar PR I opened without noticing this one:
Having to do this is a consequence of a bigger problem, namely using upper bounds in dependencies. I suspect this was initially caused by bringing development practices from JS into Python. In JS this works because the every dependency has its own subdependencies which do not intersect; in Python the dependency namespace is flat, and upper bounds cause more problems than they solve (the fact no code had to be changed after bumping the bounds illustrates that). In this PR I tried to follow the general scheme of eth-* packages to set the new upper bounds.

@fjarri Thanks for bringing this up. I've been looking into capping dependencies or not, this morning and I'll chat with the team to figure out if this is the path we want to take. The biggest con I see is that if there is a dependency upgrade and it breaks (like websockets v11 in web3.py), we have to drop everything and either temporarily cap or fix it so that CI can pass, which would be blocking to the whole team while someone is getting that fix out. It's not a huge deal, but does take time to context switch, etc.

@kclowes it is a trade-off for sure, there's no perfect solution, unfortunately. But in my experience not having upper bounds results in much fewer problems overall than having them, as long as the package is maintained. Also linking a very informative article about the issue, which may be of interest: https://iscinumpy.dev/post/bound-version-constraints/


Unable to import Grafana dashboard with Azure CLI extension

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az grafana dashboard import Extension Name: amg. Version: 2.5.3.
Errors:
The command failed with an unexpected error. Here is the traceback:
'meta'
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/azure-cli/2.67.0/libexec/lib/python3.12/site-packages/knack/cli.py", line 233, in invoke
    cmd_result = self.invocation.execute(args)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/azure-cli/2.67.0/libexec/lib/python3.12/site-packages/azure/cli/core/commands/__init__.py", line 666, in execute
    raise ex
  File "/opt/homebrew/Cellar/azure-cli/2.67.0/libexec/lib/python3.12/site-packages/azure/cli/core/commands/__init__.py", line 733, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/azure-cli/2.67.0/libexec/lib/python3.12/site-packages/azure/cli/core/commands/__init__.py", line 703, in _run_job
    result = cmd_copy(params)
             ^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/azure-cli/2.67.0/libexec/lib/python3.12/site-packages/azure/cli/core/commands/__init__.py", line 336, in __call__
    return self.handler(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/azure-cli/2.67.0/libexec/lib/python3.12/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
    return op(**command_args)
           ^^^^^^^^^^^^^^^^^^
  File "/Users/paul/.azure/cliextensions/amg/azext_amg/custom.py", line 389, in import_dashboard
    if data["meta"]["isFolder"]:
       ~~~~^^^^^^^^
KeyError: 'meta'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az grafana dashboard import --name ${AMG_NAME} --resource-group ${RG_NAME} --folder 'Azure Managed Prometheus' --definition 20331

Expected Behavior
Dashboard should import without error.
Environment Summary
macOS-15.1-arm64-arm-64bit, Darwin 24.1.0
Python 3.12.7
Installer: HOMEBREW

azure-cli 2.67.0

Extensions:
aks-preview 13.0.0b2
amg 2.5.3
azure-firewall 1.2.2
fleet 1.4.0
k8s-extension 1.6.2

Dependencies:
msal 1.31.0
azure-mgmt-resource 23.1.1

Additional Context

route to service team

Hi Team,
Below is the screenshot and changes went into 2.5.1 seems to be causing this issue.


Video support in safari on ios 15

Support for video in Safari ios 15 version

issue link

Double check on iOS Safari

Fixed to work well on ios version 15. Here is an example video.
info: ios version 15.0.2 safari
https://user-images.githubusercontent.com/40289200/140078367-759b317e-7cf9-426a-925b-79758446e43f.mov


Deprecated usage of '!' when bridging String to CFString in Request using serializeResponseString

What did you do?
Installed Alamofire using XCode 9.3 and Cocoapods 5.1
What did you expect to happen?
My project to compile without warnings
What happened instead?
⚠ Using '!' in this location is deprecated and will be removed in a future release; consider changing this to '?' instead
Alamofire Environment
Alamofire version: 4.5.1
Xcode version:  9.3
Swift version: 4.1
Cocoapods version: 1.5
Demo Project
Applies to all projects with provided setup.

Update to Alamofire 4.7.1.

Sorry, my bad. Was using Alamofire through a 3rd party dependency. Thanks!


Minor cleanups and deduplication

Deduplicate some bits and pieces

Not quite sure what the build issues are here yet and don't want to take the time to investigate at the moment so will just come back to this later.


tests: deleting stale test results when tests failed

Which feature do you think can be improved?
When debugging ARM CI failure in https://github.com/kata-containers/ci/issues/268, I found tons of stale test results under /tmp, which were traced back to hereosbuilder/tests/test_images.sh
root@arm-testing-2:~# du -k --max-depth=1 /tmp | grep "osbuilder-test"
36      /tmp/osbuilder-test.6On2ZYj
1209852 /tmp/osbuilder-test.mdWy5TB
1174800 /tmp/osbuilder-test.yH3xtJI
1174780 /tmp/osbuilder-test.HNgoRc1
1209860 /tmp/osbuilder-test.aBtTRjD
1174788 /tmp/osbuilder-test.jOmHsag
1209868 /tmp/osbuilder-test.GdEFsPu
1209860 /tmp/osbuilder-test.g7IBuy1
1051776 /tmp/osbuilder-test.TS7agUD
673268  /tmp/osbuilder-test.8OFe9vA
1209868 /tmp/osbuilder-test.7KP8xJ1
1209864 /tmp/osbuilder-test.9BWbdlN
1466152 /tmp/osbuilder-test.wmxRIRT
806748  /tmp/osbuilder-test.YvJfdKD
1210060 /tmp/osbuilder-test.3EAmdoB
1051688 /tmp/osbuilder-test.LXP7bZG
1174804 /tmp/osbuilder-test.nGoOzCI
806752  /tmp/osbuilder-test.SOQTou7
806776  /tmp/osbuilder-test.eB1ekVe
1209868 /tmp/osbuilder-test.fHiAJmX
771704  /tmp/osbuilder-test.U79Qjvl
771700  /tmp/osbuilder-test.ksJG5Bv
1174788 /tmp/osbuilder-test.ZuhvaB2
1174920 /tmp/osbuilder-test.tEqM3Vb
8       /tmp/osbuilder-test.xAvXMc3
root@arm-testing-2:~# du -k --max-depth=1 /tmp | grep "osbuilder-test" | awk '{Total+=$1} END {print Total/1024/1024" GB"}'
23.7795 GB

How can it be improved?
I found that right now we only dumped test results for debugging, when tests failed.
we should also delete them for avoiding leaving stale test results under /tmp.

Hi guys
In my another previous PR, I've set TMPDIR="/tmp/kata-containers" in slave node arm02_slave for cleaning up temp files created by kata projects, see https://github.com/kata-containers/tests/pull/2236.
but it has not gotpassed into new shell environment, when running commands like sudo -E bash ...,
like sudo -E PATH="$PATH" bash "${script_dir}/../tests/test_images.sh".
So that's why we created temp dirs osbuilder-tests-XXXXX not under /tmp/kata-containers, but still under /tmp. 😭
I'll add export TMPDIR="/tmp/kata-containers" in jenkins job http://jenkins.katacontainers.io/job/kata-containers-osbuilder-ARM-18.04-PR/ to ensure pass this variable around. ;)

@chavafg @GabyCT

/test-arm

/test-arm

@Pennyzct - might we also need a rm -rf "${tmp_dir}", which seems to be in the 'worked' path, but not in the 'failed' path?
/cc @crobinso who seems to have been in this code last ;-)
/cc @devimc who was in there before I think.

/test

thanks @Pennyzct

@grahamwhaley it seems zuul is stuck is this normal?

Occasionally (but rarely) Zuul has a glitch - sometimes it is under maintenance etc.
The status of the WIP jobs can be seen at https://zuul.opendev.org/t/kata-containers/builds?pipeline=WIP-check (you can find the links in the relevant wiki pages on the community wiki.
Looking down the status, there is a job for '443' (this PR no.), where the status is at https://zuul.opendev.org/t/kata-containers/build/ae490d72949d4a968c345c82463a7c99
It looks to have succeeded.
So, maybe it was just the reportback that didn't work. Reading that wiki page, we can twiddle a build by doing a label add/remove - let me try that ...


update polkadot package

📝 Description
Update polkadot package
❓ Context

Impacted projects: ``
Linked resource(s): ``

✅ Checklist

[ ] Test coverage
[ ] Atomic delivery
[ ] No breaking changes

📸 Demo

🚀 Expectations to reach
Please make sure you follow these Important Steps.
Pull Requests must pass the CI and be internally validated in order to be merged.

i think we need to write a test that ensure that there is no console.warn/error but the expected when doing a simple pnpm run:cli version


Add support for uyir and mei matching

Notes:

Writing Go for the first time.
Tested against cases in the attached image and a few more
Feel free to discard if you feel this will make things simple. In fact, a toggle can be added for people who wants these two additional match codes.
Doing byte comparisons. There should be a better way to encode unicode chars and do the comparison.
Attaching the test cases.

Breaking change that could impact the other UIs if they are not handling the match codes.

We can add this as a new API. We will make the existing API clients work as it is. Once both the other clients migrate to this new API, we can remove the old API.
We can probably remove the LETTER_MATCHED const. If UYIR_MATCHED and MEI_MATCHED are both set to true, the clients can automatically infer LETTER_MATCHED. But then we need an array for each letter in the http response. So we need to change the API response schema.
Also, can you use a git branch instead of a fork, so that it would be easy for me to test and run ?

Took care of your comments. Raised https://github.com/psankar/tamil-wordle/pull/6. Closing this in favor of that.


Hubblestack loader

This is a much stripped down loader that's more like what we want for hubblestack.loader. It's still extremely salt friendly for now, but I expect we'll have to do at least one more round of changes to it to get it ready for the next release anyway (eg, it's full of salt.* imports).
With this update, the tests are repaired or otherwise still working and the loader can find loadable modules in any of prefix/hubblestack/extmods/modules, prefix/hubblestack/modules, prefix/salt/modules, or /var/cache/hubble/extmods; that last one may seem suprising, but even more surprising (imo) was that previous to this change hubble would load salt modules it found in /var/cache/salt/minion/extmods without mentioning it (nightmare).
I've also renamed a mess of things to be more hubble-y instead of salt-y and I renamed __salt__ to __mods__ but left __salt__ as a working alias.
Please be critical! \o/
I want to make sure we get this piece right, so if you see something we should change for style points or correctness, definitely speak up -- but, you know, be mindful this is a first pass. I've already marked a dozen things with XXX meaning: we still need to fix this later. The correct fix for some things you spot may be marking XXX for the next pass.

Thanks for your detailed review @goravsingal. That's a lot of work.

@jettero I realized you want to merge this into develop branch.
Develop branch is the one from where we can release some feature builds. But, this code is untested and can bring whole code into an unstable state. This code should go in 4.1, which is kind of feature branch for salt-less work.

@jettero I realized you want to merge this into develop branch.
Develop branch is the one from where we can release some feature builds. But, this code is untested and can bring whole code into an unstable state. This code should go in 4.1, which is kind of feature branch for salt-less work.

I noticed this just a short while ago... then read your comment.
I changed the base branch of the PR.

@jettero I realized you want to merge this into develop branch.
Develop branch is the one from where we can release some feature builds. But, this code is untested and can bring whole code into an unstable state. This code should go in 4.1, which is kind of feature branch for salt-less work.

Further thought. 4.1 should definitely be in develop (soonishly); master should be what is currently develop and we should lose the 4.0 branch...
develop: 4.1.x -- untested, etc
master: 4.0.x
3.0: old 3.0.x support
We're not currently configured that way, but that's what the group decided I think.


训练后测试出现 size mismatch for backbone

E:\PyProject\yolox>python tools/demo.py image --conf 0.25 --nms 0.45 --tsize 640 --save_result --device [gpu]
2021-08-02 11:08:40.983 | INFO     | main:main:247 - Args: Namespace(camid=0, ckpt='./weights/nano_latest_ckpt_0801.pth.tar', conf=0.25, demo='image', device='[gpu]', exp_file=None, experiment_name='yolox_tiny', fp16=False, fuse=False, name='yolox-tiny', nms=0.45, path='./datasets/VOCdevkit/VOC2007/JPEGImages', save_result=True, trt=False, tsize=640)
2021-08-02 11:08:41.115 | INFO     | main:main:257 - Model Summary: Params: 5.04M, Gflops: 15.20
2021-08-02 11:08:41.117 | INFO     | main:main:268 - loading checkpoint
Traceback (most recent call last):
File "tools/demo.py", line 303, in
main(exp, args)
File "tools/demo.py", line 271, in main
model.load_state_dict(ckpt["model"])
File "C:\ProgramData\Anaconda3\lib\site-packages\torch\nn\modules\module.py", line 1051, in load_state_dict
raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
RuntimeError: Error(s) in loading state_dict for YOLOX:
size mismatch for backbone.backbone.stem.conv.conv.weight: copying a param with shape torch.Size([32, 12, 3, 3]) from checkpoint, the shape in current model is torch.Size([24, 12, 3, 3]).
size mismatch for backbone.backbone.stem.conv.bn.weight: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.stem.conv.bn.bias: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.stem.conv.bn.running_mean: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.stem.conv.bn.running_var: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.0.conv.weight: copying a param with shape torch.Size([64, 32, 3, 3]) from checkpoint, the shape in current model is torch.Size([48, 24, 3, 3]).
size mismatch for backbone.backbone.dark2.0.bn.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
size mismatch for backbone.backbone.dark2.0.bn.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
size mismatch for backbone.backbone.dark2.0.bn.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
size mismatch for backbone.backbone.dark2.0.bn.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
size mismatch for backbone.backbone.dark2.1.conv1.conv.weight: copying a param with shape torch.Size([32, 64, 1, 1]) from checkpoint, the shape in current model is torch.Size([24, 48, 1, 1]).
size mismatch for backbone.backbone.dark2.1.conv1.bn.weight: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv1.bn.bias: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv1.bn.running_mean: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv1.bn.running_var: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv2.conv.weight: copying a param with shape torch.Size([32, 64, 1, 1]) from checkpoint, the shape in current model is torch.Size([24, 48, 1, 1]).
size mismatch for backbone.backbone.dark2.1.conv2.bn.weight: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv2.bn.bias: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv2.bn.running_mean: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv2.bn.running_var: copying a param with shape torch.Size([32]) from checkpoint, the shape in current model is torch.Size([24]).
size mismatch for backbone.backbone.dark2.1.conv3.conv.weight: copying a param with shape torch.Size([64, 64, 1, 1]) from checkpoint, the shape in current model is torch.Size([48, 48, 1, 1]).
size mismatch for backbone.backbone.dark2.1.conv3.bn.weight: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
size mismatch for backbone.backbone.dark2.1.conv3.bn.bias: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
size mismatch for backbone.backbone.dark2.1.conv3.bn.running_mean: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
size mismatch for backbone.backbone.dark2.1.conv3.bn.running_var: copying a param with shape torch.Size([64]) from checkpoint, the shape in current model is torch.Size([48]).
后面还有很多 mismatch 的信息，就不打印了，不知道这是什么错误，求大神指教

Args: Namespace(camid=0, ckpt='./weights/nano_latest_ckpt_0801.pth.tar', conf=0.25, demo='image', device='[gpu]', exp_file=None, experiment_name='yolox_tiny', fp16=False, fuse=False, name='yolox-tiny', nms=0.45, path='./datasets/VOCdevkit/VOC2007/JPEGImages', save_result=True, trt=False, tsize=640)
your network is yolox-tiny, but you load yolox-nano's weight


panic: close of closed channel

Not sure how this might happen but I got:
panic: close of closed channel

goroutine 15 [running]:
github.com/wagslane/go-rabbitmq.(*channelManager).startNotifyCancelOrClosed(0xc0000c4840)
        /var/lib/jenkins/go/pkg/mod/github.com/wagslane/go-rabbitmq@v0.6.2-0.20210618171750-0f20affc2859/channel.go:85 +0x1c5
created by github.com/wagslane/go-rabbitmq.newChannelManager
        /var/lib/jenkins/go/pkg/mod/github.com/wagslane/go-rabbitmq@v0.6.2-0.20210618171750-0f20affc2859/channel.go:35 +0x21a

It is probably happening because channel was closed inside NotifyCancel method https://github.com/wagslane/go-rabbitmq/blob/0f20affc2859ccb8250fd0380994c324ef2c287f/channel.go#L59

So I was building a new AMQP producer application. I originally went for implementing all the connection handling logic on top of streadway/amqp, but after seeing how much complexity I'd need to maintain I decided to take another look at this lib.
Currently this issue is what's preventing me from using it though, as the system I'm working on cannot have panics in production as I don't control all deployments.
I think the correct fix here would be to not close the notification channels, since when we call Notify* on the *amqp.Channel it actually takes ownership of the channel and necessarily closes it on shutdown. There's also no problem leaving a channel open indefinitely, only if there are receivers blocked on it (if there's a sender blocked and we close the channel they will panic anyway, so not much we can do).
So all we need is to remove the code that closes those channels and add a minimum buffer of 1 to them , as suggested in some amqp examples as well. WDYT?

I'm very sorry I don't have time this week to look at it, maybe next week?
That said, always feel free to open a PR as I can review code faster than
writing it.
On Mon, Jul 12, 2021, 5:15 PM Victor Elias @.***> wrote:

So I was building a new AMQP producer application. I originally went for
implementing all the connection handling logic on top of streadway/amqp,
but after seeing how much complexity I'd need to maintain I decided to take
another look at this lib.
Currently this issue is what's preventing me from using it though, as the
system I'm working on cannot have panics in production as I don't control
all deployments.
I think the correct fix here would be to not close the notification
channels, since when we call Notify* on the *amqp.Channel it actually
takes ownership of the channel and necessarily closes it on shutdown.
There's also no problem leaving a channel open indefinitely, only if there
are receivers blocked on it (if there's a sender blocked and we close the
channel they will panic anyway, so not much we can do).
So all we need is to remove the code that closes those channels and add a
minimum buffer of 1 to them , as suggested in some amqp examples as well.
WDYT?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/wagslane/go-rabbitmq/issues/28#issuecomment-878658980,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFHZKVNLNF2TMGTCTDOTQ43TXNZPVANCNFSM5ACUVCLA
.

@wagslane done! :)
https://github.com/wagslane/go-rabbitmq/pull/29


Reminders

a command that will tell the bot to notify you at the specified time (both relative and absolute option of specifying time)
others could join the reminder by clicking on emoji on the command
Možné užití
.reminder 2020-06-06T12:00:00 implement reminders to honza botner
.remainder in 12h online fit beer

Should we support here only English or be able to handle Czech too?

Also, reacting :watch: should add the user to the reminder.


Support for other DEs?

I am using i3 & kde.
The script works wonderfully in i3. No issues at all.
However it also almost works perfectly on KDE.
The one issue I face is that during suspend (I've enabled the systemd service), betterlockscreen gets called and on top of that sddm's own lock screen gets called too, leading to 2 lockscreens at a time.
I checked sleep.target.wants/  and suspend.target.wants/: to see if theres any service of sddm there but there isnt.
Is there a way i can disable sddm's lockscreen and/or make kde use betterlockscreen?

i don't use kde, but can't you just go to KDE System Settings > Desktop Behavior > Screen Locking and disable it?

i don't use kde, but can't you just go to KDE System Settings > Desktop Behavior > Screen Locking and disable it?

Yeah! System Settings > Desktop Behavior > Screen Locking > Lock screen on resume was enabled. It's all good now thanks!


Fetch ETCD Quorum Check fix for Unknown Guard Pod State

The fix includes the scenario where the guard pod is pending and the condition Ready is missing. Unknown guard pods state.
Follow up to https://github.com/medik8s/node-maintenance-operator/pull/110

Considering that the actual fix is inside common and that this commit "only" picks the new version, it is not clear what part of NMO would be affected. Could you rephrase the commit message to clarify that?

/retest


fix: migration script message formatting issue

SUMMARY
Fix a tiny formatting issue in superset db history
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before

After

TEST PLAN
Run superset db history | more
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #13262 (f067856) into master (2ce7982) will increase coverage by 0.66%.
The diff coverage is 61.09%.

@@            Coverage Diff             @@
##           master   #13262      +/-   ##
==========================================
+ Coverage   53.06%   53.72%   +0.66%
==========================================
  Files         489      464      -25
  Lines       17314    15705    -1609
  Branches     4482     4028     -454
==========================================
- Hits         9187     8438     -749
+ Misses       8127     7267     -860

Flag
Coverage Δ

cypress
53.72% <61.09%> (+0.66%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...erset-frontend/src/SqlLab/components/ResultSet.tsx
4.16% <0.00%> (-0.09%)
:arrow_down:

...end/src/SqlLab/components/RunQueryActionButton.tsx
52.77% <ø> (ø)

...erset-frontend/src/SqlLab/components/SqlEditor.jsx
54.46% <ø> (ø)

...end/src/SqlLab/components/TemplateParamsEditor.jsx
23.80% <ø> (ø)

superset-frontend/src/chart/ChartContainer.jsx
100.00% <ø> (ø)

superset-frontend/src/chart/ChartRenderer.jsx
75.67% <0.00%> (-1.04%)
:arrow_down:

...perset-frontend/src/common/components/Dropdown.tsx
50.00% <ø> (ø)

...t-frontend/src/common/components/Tooltip/index.tsx
100.00% <ø> (ø)

...perset-frontend/src/components/AlteredSliceTag.jsx
92.00% <ø> (ø)

superset-frontend/src/components/CachedLabel.jsx
42.10% <ø> (ø)

... and 217 more

Continue to review full report at Codecov.

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

Thanks for the stamp, @willbarrett !


Program exception while creating a channel

I downloaded OBWallet and tried to open some channels. But when I press “Create” (to create a channel), I always get an error: “Sorry, the program encountered an exception and is about to exit”.
I tried two versions: 0.1.5 and 0.1.3.
I used them on two smartphones: Pixel 5a and Honor 9.
I tested both mainnet and testnet.
There is the same issue in all the cases.

fixed

This exception is caused by an input widget and has been fixed


Introduce new API version for Microsoft.ProviderHub 2021-09-01-preview

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that label “WaitForARMFeedback” will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

@laxmankumar12 please help fix the avocado and prettier check issues https://github.com/Azure/azure-rest-api-specs/pull/15723#issuecomment-902347745

@laxmankumar12 , can you attach the previous PR link so that we can approve this PR?

@laxmankumar12 , can you attach the previous PR link so that we can approve this PR?

@raych1 @zhenglaizhang Please check this PR. It was to add 2021-06-01-preview and got approval for breaking change. #14650

@raych1 @zhenglaizhang Could someone please check this PR?

Hi @hjhhh3000vitae @laxmankumar12
In the previous PR #14650 you have got approval for RemovedProperty breaking change, and in this PR, you have adding a required property in input, so you need do breaking change review for this change.

Hello @zhenglaizhang Thank you for pointing out. This was due to a new change we did not pick up in this PR. I've updated this PR. Now there is only removeProperties breaking changes. Please take a look.

Hi @hjhhh3000vitae @laxmankumar12
In the previous PR #14650 you have got approval for RemovedProperty breaking change, and in this PR, you have adding a required property in input, so you need do breaking change review for this change.

Hello @zhenglaizhang Thank you for pointing out. This was due to a new change we did not pick up in this PR. I've updated this PR. Now there is only removeProperties breaking changes. Please take a look.

Kindly ping. @zhenglaizhang @raych1

Hi @hjhhh3000vitae @laxmankumar12
In the previous PR #14650 you have got approval for RemovedProperty breaking change, and in this PR, you have adding a required property in input, so you need do breaking change review for this change.

Hello @zhenglaizhang Thank you for pointing out. This was due to a new change we did not pick up in this PR. I've updated this PR. Now there is only removeProperties breaking changes. Please take a look.

Kindly ping. @zhenglaizhang @raych1

Kingly ping. @zhenglaizhang @raych1

Signing off from ARM side.


v5.0.0

As iOS 18 / Android 15 are around the corner, it's time to publish a new major version, as it will needs the latest Xcode version (v16) to be built. Let's perform some changes to improve this library in the same time.
I'm opening this to discuss about some points. I think it will be for the better, but I would love a community confirmation about them:

Add limited contacts support (on iOS 18+) ✅
Drop support for iOS < 13.4 ✅
Drop support for Android < 6.0 ✅
~Remove the UNAVAILABLE status, return BLOCKED instead (as it cannot be requested). That's one less thing to check, and it allows me to solves this issue.~
Migrate the Android code to Kotlin ✅
~Make check and checkMultiple synchronous~
~Make check and checkMultiple return a boolean (granted) (as Android will never return blocked on check, you have to call request to get the info anyway)~

And, this is extra, but:

Add hooks. const [granted, request] = usePermission(…) might be a thing, let's see how we can make it reactive.
Allow location permission escalation (closes https://github.com/zoontek/react-native-permissions/pull/716) ✅
Add SCHEDULE_EXACT_ALARM permission (closes https://github.com/zoontek/react-native-permissions/pull/878)

About hooks and reactivity, especially in context of permissions, this github thread at expo has some interesting insight on the API design: https://github.com/expo/expo/pull/31171#discussion_r1731486654

Hooks!

I published a first beta, try it: yarn add react-native-permission@next / npm i --save react-native-permission@next
For the moment, the check method is not synchronous on windows so it's mostly for iOS and Android target, let's see if someone publish a PR for this platform.
First beta changelog

Drop support for React native < 0.73, iOS < 13.4 and Android < 6
Add LIMITED contacts permissions support (requires Xcode 16 beta)
Rewrite android codebase in Kotlin
Remove the UNAVAILABLE status, BLOCKED is now returned in such cases
Unify all platforms to a unique permission flow
check, checkMultiple and checkNotifications now return granted boolean instead of statuses (as it was not truly possible on Android to determine if it was BLOCKED without requesting it anyway)
check and checkMultiple are now synchronous (please provide feedbacks on this, especially on the performance side for the old architecture - this is not guarantee to stay in the stable version)
requestNotifications now accept a rationale argument

Juste published beta 2 to fix an issue with bob + the expo plugin (more infos https://github.com/callstack/react-native-builder-bob/pull/598#issuecomment-2350930474)

I don't quite understand what the flow would be to check and then request permissions if the check method returns a boolean.  what if a user provides limited permissions but I want to force granted permissions.  how would i know that permissions are limited and present user to click on a button to be redirected to Linking.openSettings().

@valeeum The flow is aligned to the Android one.
In your example, request resolve with a PermissionStatus, so you can verify if it's GRANTED or LIMITED, and no need to redirect the user to settings in such case.

Published beta 3 with iOS location permission upgrade support.

I have verified the iOS location permission upgrade from "when in use" to "always", it works great 👍 Thank you for adding that 🙏

@martinpoulsen You are not the only company that reached me about this.
I rolled back to UNAVAILABLE (as it's useful in some context, for example to detect if the device has Face ID, etc) and status, but managed to solve the calendar permission escalation issue on iOS.
As the Android limitation is not well understood, I also improved the documentation with a unique flow, and a flow implementation example:

I also used GH flavored markdown to add important alerts:

This should be good for the stable release. I published a RC version, will publish the stable one next week.

I published it, will see for other features (hooks, the SCHEDULE_EXACT_ALARM permission) later.

I tried it then I still curious why the POST_NOTIFICATIONS is gone

I tried it then I still curious why the POST_NOTIFICATIONS is gone. I attached image that display POST_NOTIFICATIONS is used. if it's need to remove from react-native-permission so how I solve the case?

Facing the same issue. I couldn't find  POST_NOTIFICATIONS permission for Android after upgrading to 5.0.0.

@rukchatpoomw @arlovip Because POST_NOTIFICATIONS is not retro-compatible / multi-platform. The preferred way has always been checkNotifications / requestNotifications that handle both of these.

Get it now, thanks a lot!

@arlovip Yeah, I removed it as a lot of people didn't know about checkNotifications / requestNotifications, just performed a runtime check on the Android version and handle the Android 13+ case, assuming that your app notifications cannot be disabled on Android 12-. But they can.


Feature Request: allow setting coupon code from the Buycraft command

Hi there,
Thanks for taking the time to report this issue, I'm sorry it's been slow to get resolved — we're working on it!
Unfortunately, this issue is old enough that we've had to close it. But if you see any other issues (especially ones with the same or similar symptoms), please reply here and I'll look into getting them fixed.
We are currently planning a recode of the Buycraft plugin at some point in Q2 of this year, and we would love to know what issues still exist so they can be fixed for the new plugin.
Apologies for the issues you have faced!

Hi there,
Thanks for taking the time to provide this suggestion, I'm sorry it's been slow to reply to your idea — we're working on it!
We are currently planning a recode of the Buycraft plugin at some point in Q2 of this year, and I will happily note this idea down for the recode.
Thanks for providing a cool suggestion :)


[Substrate.io] Chain Specification

The "Chain Specification" page was migrated from Substrate.io: https://docs.substrate.io/build/chain-spec/

Disclaimer - I'm taking over this PR and will move it to the "Generate Chain Specs and WASM" page under the Deployment section of the new IA

https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/chain_spec_genesis/index.html

Good point! Added.


Add region kw argument to login.

As mentioned in this story, there are several ways to allow users to specify the region:

Modify tiledb.cloud.client.config.config.host directly, which is the status quo.
Add a region keyword argument to classes like DAG, Delayed, etc.
Specify the region as part of logging in (this PR implements a PoC).

The first option is confusing to customers, so we need a better approach. I've been playing with the second approach and find it confusing too: It's easy to forget to pass the region argument. Besides, if a user wants to run a task graph in region A, odds are that they want all their code to run in region A. The third approach strikes me as the safest and least confusing but it feels odd having to specify the region as part of the login function, like so:
tiledb.cloud.login(..., region=tiledb.cloud.AwsRegion.AP_SOUTHEAST_1)

Or perhaps we should instead expose a new function, like tiledb.cloud.set_region()? Any thoughts on this?

In short, to me,
tiledb.cloud.login(host=tiledb.cloud.Region.AWS.US_EAST_1)

(or maybe make region into a module, tiledb.cloud.regions)
seems like a perfectly reasonable thing to write, and doesn’t require any new functions.

See e5401a6.


Enable cqf expressions to evaluate variables on questionnaire extensions

Is your feature request related to a problem? Please describe.
The current problem is the inability to pass a saved date value to be used as a questionnaire date picker validation value i.e. using the dob as a minimum value to capture any patient-related services like immunization. This requires passing the already saved dob to used a min date on the questionnaire date picker. The cqf currently fails to evaluate the variable passed.
Describe the solution you'd like
Allow the cqf expression to access and evaluate expressions for parameters stored/passed in the launch context
Describe alternatives you've considered
prepopulating the questionnaire with the dob value and passing that as an express dob value
Additional context
The extension below currently works for max value validation, this feature should allow the use of the same extension or min value validation
{
              "url": "http://hl7.org/fhir/StructureDefinition/maxValue",
              "valueDate": {
                "extension": [
                  {
                    "url": "http://hl7.org/fhir/StructureDefinition/cqf-calculatedValue",
                    "valueExpression": {
                      "language": "text/fhirpath",
                      "expression": "today()"
                    }
                  }
                ]
              }
            }

Would you like to work on the issue?
Yes

just to clarify.
we'll be passing declared variables, launchContexts, %resource, and other FHIRPath context variable when we evaluate the cqf-calculated-value for both min and max validator


Add ELB tags

Hi!  This patch has been working in our environment for a number of months but I recall now why I delayed in sending a pull request.  It adds substantial load to the AWS API due to querying for tags on every ELB individually.  I plan on altering it to perform batch requests to Amazon but haven't gotten around to implementing that yet.

Might also be useful to have an option to disable it. Then users could choose if they want to have the additional calls.

@bradbenvenuti @wstrucke there are two new pull request, both are related to ELB.
https://github.com/Netflix/edda/pull/117 --> adding pagination for elb crawler
https://github.com/Netflix/edda/pull/112  --> Add support for elbv2
If someone can review/merge all these in single pull request, that will be great.

@wstrucke thanks for adding ELB tag part.
could you pick the latest code which has "pagination for elb crawler"
#117 --> adding pagination for elb crawler
Also could you address @brharrington comments as well?

An option to disable the querying of tags can come later if someone has the time to create a PR. Minor changes have been addressed and conflicts resolved with master branch.


Implement multifile support in both edit and run mode.

Description
I'd like to host multiple notebooks (and hence apps) via a single marimo command. This opens up multiple usecases for end users.
Eg:
marimo edit file1.py file2.py file3.py
In the view - There's a dropdown at the top to activate one of the 3.
Similarly:
marimo run file1.py file2.py file3.py
In the view - i switch over b/w the 3 as needed.
This allows lightweight selection of apps to be hosted via a single instance on production.
Suggested solution
A user flow of solution is suggested in description above.
Alternative
No response
Additional context
No response

Thanks for the feature request, and the suggested user flow. This is something several people have asked for, so we are thinking about it. I've added it as an item to our roadmap.


Feature/uuid and faker data

I have added 2 new methods on DataSet:

uuid_data (generate random uuids)
faker_data (generate any faker provider data, as ipv6...)

I have also update README.md, added CHANGELOG.md, unit tests on these methods.

Thanks for submitting this. I plan to review this shortly and then we can cut a new release after merge.

I promise im still on top of this! I plan to play with it this week!

Hi @Gmousse ,
Nice PR! Can you add some docs detailing the different types of uuid's that a user can specify? I noticed in  your example that 'ipv6' was one of them but wasn't sure what the others were?

The uuid_data generator I have used here is the standard uuid v4 (from python uuid.v4()) which has is 128 bits value.
Example of a uuid (36 characters):

123e4567-e89b-12d3-a456-426655440000

By using the new faker_data you can use each type allowed by faker (already used internally in this library). Please refer to the official faker documentation: http://faker.readthedocs.io/en/master/.
If @jbrambleDC is ok with that, I can edit the README.

Sorry i meant to say the types for faker_data, not uuid! Adding the link to the README is a good idea.

I would also be in favor of adding a link to the faker docs and a short description of how to use the method. Extensive detail won't be necessary, but something that lets users know its available without reading over the source code would totally be helpful! Thanks!

Ok I will edit the README quickly.

@jbrambleDC @saidmasoud  I have edited the README, adding a simple use case.

@Gmousse nicely done!

@jbrambleDC Have you some update about a release date ?

yes. I am going to be off work for the christmas holidays starting tomorrow, and over the holidays I will test and release. sorry about this, just a few more days!

Thank you so much for being patient @Gmousse . This is awesome work. Really spectacular thinking  on adding a vanity Method for all Faker functions. make these last few changes and I will merge and release

one final request, can we add the tests to the setup.py so we can run them by doing python setup.py test ? post output here for verification! Thanks!

@jbrambleDC Hey, I will look for the revisions this night and I will see for the tests !

@jbrambleDC It should be ok.
I added unit tests on python setup.py test (It could interesting to plug travis) and fixed everything.

LGTM! thanks for all your hard work. I will cut a release later tonight!

0.3 release cut! Thanks @Gmousse & @saidmasoud 💯


Problem during pyethapp compilation and pickle

Checklist

[ ] installed HomeBrew
[ ] installed HomeBrew dependencies
[ ] installed HomeBrew Python

System/environment

OS: MC OSX Sierra
python version: 2.7.13
pyethapp version: GITHUB clone
installation method (pip & pypi/git & setup.py): USE_PYETHEREUM_DEVELOP=1 python setup.py develop

Observed behaviour
Traceback (most recent call last):   File "setup.py", line 97, in <module>     '''   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py", line 151, in setup     dist.run_commands()   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 953, in run_commands     self.run_command(cmd)   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command     cmd_obj.run()   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/develop.py", line 36, in run     self.install_for_development()   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/develop.py", line 150, in install_for_development     self.process_distribution(None, self.dist, not self.no_deps)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 746, in process_distribution     [requirement], self.local_index, self.easy_install   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/pkg_resources/__init__.py", line 852, in resolve     dist = best[req.key] = env.best_match(req, ws, installer)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1124, in best_match     return self.obtain(req, installer)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1136, in obtain     return installer(requirement)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 673, in easy_install     return self.install_item(spec, dist.location, tmpdir, deps)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 699, in install_item     dists = self.install_eggs(spec, download, tmpdir)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 880, in install_eggs     return self.build_and_install(setup_script, setup_base)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1119, in build_and_install     self.run_setup(setup_script, setup_base, args)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1105, in run_setup     run_setup(setup_script, args)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/sandbox.py", line 257, in run_setup     raise   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/contextlib.py", line 35, in __exit__     self.gen.throw(type, value, traceback)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/sandbox.py", line 199, in setup_context     yield   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/contextlib.py", line 35, in __exit__     self.gen.throw(type, value, traceback)   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/sandbox.py", line 170, in save_modules     saved_exc.resume()   File "/Users/Andrea/Documents/Ether/ether/lib/python2.7/site-packages/setuptools/sandbox.py", line 144, in resume     type, exc = map(pickle.loads, self._saved)   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1388, in loads     return Unpickler(file).load()   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 864, in load     dispatch[key](self)   File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1139, in load_reduce     value = func(*args) TypeError: __init__() takes at least 3 arguments (1 given)
Steps to reproduce
clone pyethapp from github
setup develop

I hit the same issue, brew install autoconf fixed it for me


How to trigger the autocomplete

Can I manually trigger the autocomplete function?
I want to do something along the lines of...
//usual initialization of easyautocomplete on ".autocomplete_input"
//when specific/external event happens...
var someNewValueIWantToAddWithJavascript = "United Kingdom";
$(".autocomplete_input" ).val(someNewValueIWantToAddWithJavascript);
$(".autocomplete_input" ).trigger("change"));

But the trigger("change") doesn't trigger the ajax call for autocomplete and so the results list never displays. I figure there must be an easy way to do this, but I've tried several triggers and to no success.

same problem here, have you solved it?

Try 'trigger('focus').

Wondering the same thing ...

There is no trigger event, but this workaround works for me:
var e = jQuery.Event("keyup");
e.which = 8; //choose the one you want
e.keyCode = 8;

$(input).val(value).trigger(e);

I made some changes to the file, and now I can do
$(input).val(value).trigger('change');

jquery.easy-autocomplete.js.zip

I made some changes to the script:
jquery.easy-autocomplete.js.zip
and now I can do this:
$(input).val(value).trigger('change');

You can just use key 41
var evt = jQuery.Event("keyup");
evt.keyCode = 41; // 41 key is for select
$(e.target).trigger(evt);

It quite annoying that this has to be done this way, but that fine.

@socheatsok78 you save my day! thanks!


Update _helpers.tpl

修复k8s识别数据源错误，导致pgsql在k8s环境下sql语法错误

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

(or)
If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

https://github.com/apache/dolphinscheduler/issues/13517

Please provide your version, error logs, and detailed steps to reproduce the issue. If this problem exists, it should not pass the CI check. It is recommended to create a new issue to confirm the problem before creating a PR to fix it. Thanks.


mini.menu

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md

Module(s)
None
Description
Hello,
I developed some times ago a simple plugin to create a menu for leader key mapping, like present in Spacemacs. I tried Spacemacs and I found their menu is awesome.
I just ported my Neovim setup to use a Lua-based init file and I'm considering porting my plugin in Lua. Would you be interested to add it in your mini collection? My plugin is easy to configure from a vim script or Lua dictionary and bind any regular command or function call. The plugin doesn't have code dependency.
BTW, thanks for your work, I love your plugins :)
Damien

Thanks for suggestion! I've looked at your plugin: it is quite nice and simple. And the fact that it is older than any of 'mini.nvim' modules says a lot about its quality!
I have similar module in mind, named 'mini.clue' (but I quite like the 'mini.menu' name, although it is even more ambiguous than 'mini.clue'). It has some specific goals and approaches in mind. There is some discussion about it in #118.
So I am afraid I am going to say no to this, sorry. Hope you'll still like and use 'mini.nvim' after that :)


Fix net tests

There was a silly error where a bunch of Net::sm* stuff was being declared as standalone static variables rather than as static members.

Formatting tabs vs spaces in this PR too. :/

Should be all set.


“Unexpected token ...” (object spread) when using .eslintrc.js

Hello. This eslint config is valid JavaScript but makes the ESLint server crash with Unexpected token ....
const myGlobals = { globalA: 'A', globalB: 'B' }

module.exports = {
  globals: {
    LIVE: true,
    PRODUCTION: true,
    DEVELOPMENT: true,
    ...myGlobals
  }
}

I guess it isn’t using my current node version (latest, v9) but some other version that doesn’t support spreading? When I start the VSCode debugger, it says it is indeed using v9… I’m not too sure what’s happening as I expect my extensions to use my node version?
I could obviously use Object.assign instead, but… 😄

The language server uses VS Codes shipped node version which is 7.9.0. I will mark this as a feature request to support using a different node version.

Oh, okay. I might give it a try myself if I ever have the time. Thank you.

@dbaeumer how would you feel about having a preference named eslint.nodeCmd that allows you to specify the path to a custom version of Node to use when launching eslint?
I started looking into this, but am not sure if the CLIEngine that eslint exports runs as a separate process or as a JS function in the current process. If it's a separate process it should be possible to change use a custom node path without too much hassle. If it runs it all in the same process though I'm not sure what the best approach would be.
If you have any suggestions on how to approach this I'm happy to give it a go.

@jasonb01: the CLIEngine is already running in VS Code shipped node version. So the setting needs to be interpreted on the client side. The Server options to the LSP client already take a runtime attribute (see https://github.com/Microsoft/vscode-eslint/blob/master/client\src\extension.ts#L354). So all that needs to be done is to set that runtime to the installed node version to use.
I would name the setting eslint.server.runtime. If you need further assistance feel free to ping.

@dbaeumer Where would be best to file an issue to update the version of node shipped with VSCode? Or do you know if there is one already?

The version of Node that ships with VS Code depends on the Electron version used by VS Code. This got lately updated to Electron 2.0 which now uses node 8.9.3 which should make the error go away. In addition there is https://github.com/Microsoft/vscode-eslint/pull/516 which will let you control the node version.


Update peek.rb

Turned multiline operations into one line ones where possible
Changed Hash style to literal
Removed excess ()s
Changed {} to Hash.new
Changed [] to Array.new
Changed '' to String.new

I'd like to not dirty the git blame for stylistic changes when there are no functional changes attached with the PR. I appreciate you taking the time to open this PR but I'm afraid I'm going to have to not merge it at this time.


ClassNotFoundException when forwarding events from S3 to Elastic Cloud

Hi,
I've been pulling my hair over this issue however unable to solve it
I am following the Cloudflare's official documentation, linked here
I have added the function to lambda and provided the relevant role. However, while testing the code, I am getting the following error:
{   "errorMessage": "Class not found: com.cloudflare.elastic.ElasticLambdaForwarder",   "errorType": "java.lang.ClassNotFoundException" }
I dont know if this is something that is frequent or not
The runtime im using is Java 8 on Amazon Linux 2. I have tried it with AL1 and Java 11 Corretto as well but the same error as there
I am using the following as my handler: com.cloudflare.elastic.ElasticLambdaForwarder::handleRequest
Further, the release Im working with is as follows:
https://github.com/cloudflare/cloudflare-elastic/releases/tag/v0.3-7.x
I have been searching for quite a few days and unable to find any solution as of yet :(

@aleph-zero if you can assist with this ? Thank you !!
i have been searching long and hard and unable to find any resolution

Hi,
So for anyone running into this issue in the future.
What actually was happening that the link in the documentation for code for the Lambda function is actually redirecting to the code that first needs to be built through the following command:
./gradlew clean build
You can either build it yourself ( you would need JRE and JDK both ) or use the one of the previous releases for fetching the already built lambda function code here
Further, if you run into this issue later down the line, please ensure the following to start receiving logs into the proper ElasticSearch Index:
Create an index by the name of cloudflare-test through the following request
curl -X PUT "localhost:9200/cloudflare-test?pretty"
Download the index templates from the same release i.e.
Issue the following command through terminal from your own computer:
./install-artifacts.sh -u elastic -p  -e https://:9243
After this, you should hopefully see the following output:
Installing ingest pipeline to https:// for daily indices {"acknowledged":true} Installing ingest pipeline to https:// for weekly indices {"acknowledged":true} Installing index template to https:// {"acknowledged":true}
After which the logs should start appearing on Kibana


Looking to contribute at Apni Kaksha

Hi Anuj, is there anything I can contribute in your repository? I would to like to help you in your mission to educate students and prepare them for placements. Please view my GitHub profile, and if you find me eligible, let me know how I can contribute to this repository.

Yes, you are free to contribute. but It's not an "Issue" 😄 right?


"//" Gets token operator instead of token comment

The html is this:
//
When it should have been this
//
or ?
//
My prism js is this:
css+clike+javascript+c+csharp+css-extras+objectivec+php+php-extras+python+ruby+scss+swift

Oops, sorry! Which language does the issue happen in? Swift, I guess (judging by the comment)?

That is correctly guessed - sorry, forgot to mention that :)

ping @chrischares

Actually, this might be a problem in C-like.
Do all C-like languages allow empty single-line comments? If so, it should definitely use .* instead of .+ in the regex...
https://github.com/PrismJS/prism/blob/gh-pages/components/prism-clike.js#L8

I can say PHP does. You know JS does, obv. Dunno about the rest but probably?

I guess we can assume all of them do, then. I'll make the change right now. We'll make exceptions for those that don't allow empty single-line comments, if any. It seems more natural to me this way.

great


Snapshot rendering helper: add support for gaussian splatting meshes

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

This doesn't look like a maintenable fix. Thin instances update would need such hack (and any object inheriting from thin instances). Is it because of the vertex buffer update or another limitation?

Snapshot stored with reference name:
refs/pull/15906/merge
Test environment:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15906/merge/index.html
To test a playground add it to the URL, for example:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15906/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15906/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15906/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15906/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15906/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15906/merge#BCU1XR#0

Visualization tests for WebGPU (Experimental)
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15906/merge/testResults/webgpuplaywright/index.html

WebGL2 visualization test reporter:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15906/merge/testResults/webgl2playwright/index.html

I'm not sure why this isn't maintainable? Mesh.render isn't called when snapshot rendering is enabled, so the solution is to have the helper make the call itself. Can you think of another way of doing this? Note that the fix is not linked to thin instances, it simply does “manually” what is no longer done automatically.


use loadchild lazy loading routeComponent,but is bug

ERROR in D:/git-angular2/ng4-boot4/src/app/beneform4j/web/rootmodule/route.config.ts (7,7): Type '({ path: string; loadChildren: typeof IndexComponent; } | { path: string; component: typeof Detai...' is not assignable to type 'Route[]'.
  Type '{ path: string; loadChildren: typeof IndexComponent; } | { path: string; component: typeof Detail...' is not assignable to type 'Route'.
    Type '{ path: string; loadChildren: typeof IndexComponent; }' is not assignable to type 'Route'.
      Types of property 'loadChildren' are incompatible.
        Type 'typeof IndexComponent' is not assignable to type 'LoadChildren'.
          Type 'typeof IndexComponent' is not assignable to type 'LoadChildrenCallback'.
            Type 'typeof IndexComponent' provides no match for the signature '(): Type<any> | NgModuleFactory<any> | Promise<Type<any>> | Observable<Type<any>>')

I'm sorry, but I have no idea of what you're trying to say. You seem to have a type error. Please open a new issue and fill in the template so we can help you.

Hi @filipesilva  ,
I also get this error when I upgraded to Typescript 2.4 and I guess this is due to weak type checking that introduced by the new version of  Typescript?
    { path: "reporting/home/home", component: HubComponent, canActivate: [CanRouteActivate], canDeactivate: [CanDeactivateRoute] },

    { path: "reporting/overviews", loadChildren: './overviews/overviews-ng2.module#OverviewsModule' },
    { path: "reporting/statistics", loadChildren: './statistics/statistics-ng2.module#StatisticsModule' },
    { path: "reporting/other", loadChildren: './other/other-ng2.module#OtherNg2Module' },
    { path: "reporting/commissions", loadChildren: './commissions/commission2.module#CommissionModule' },
    { path: "reporting/custom-field", loadChildren: './custom-field/custom-field-ng2.module#CustomFieldModule' }

];

The above configuration wok for Typescript 2.3.2


Rename removing-workflow-artifacts.md to newremoving-workflow-artifac…

…ts.md

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[x] This pull request impacts the contribution experience

[x] I have added the 'writer impact' label
[x] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

new


Readme Has Invalid Example

Version
1.9.1
Test Case
None
Steps to reproduce
Visit GitHub front page
Expected Behavior
Example actually works.
Actual Behavior
The example violates the library's own rules, because it includes:
<MenuItem data={"some_data"}

First off, you don't need {} to pass a string property in React, but more importantly you can't pass a string as data in react-contextmenu; if you try you get a PropType warning: "Failed prop type: Invalid prop data of type string supplied to MenuItem, expected object."
The example should be something more like:
<MenuItem data={{some: `data`}}

Obviously this isn't the most important bug, but still,  do you really want new users' first experience with the library to be a "you just did something wrong" warning when all they did was copy/paste the example code?

Can you open a PR?

Can you not just fix this issue yourself, as you are the original dev? Expecting people to fix your plugin is just lazyness.

@hybridwebdev What is your issue? Why are you so pessimistic?
I have a full time job and I maintain this package in my free time.
I ask people to open a PR, so that they can start contributing to open-source and not due to laziness.

@hybridwebdev Asking for a PR is pretty standard OSS etiquette (even for small fixes like this).
@vkbansal Unfortunately I'm a bit swamped ATM, but when I have some time I'll try and submit one.

@machineghost No issues. Take your time.

@machineghost and @vkbansal
Created pull request #208 for this. If you could review that PR to confirm that's correct. Basically just a readme update.


Fix workspace fallback to global binary config

Fixes #28
Solution ended up being pretty simple. Long-winded explanation in my issue comment.

lgtm, merging!
Thank you @jasonvarga!

I guess there are some other cases that need to be covered. (#32) Sorry about that. 😕

No prob, there's a lot of use cases for this, that's mainly my issue of not being able to write any tests


Space between symbols

(I'm using the version from brew cask)
When pressing "F12" it will be indistinguishable from simply typing "F", "1", "2" which also displays as "F12".
I just realized that I can set a low "Keystroke Delay"; regardless, it should still work when showing presses in a horizontal line.

These are in fact distinguishable in the sense that "F12" appears all at once, and "F", "1", "2" appear one at a time. You've also observed that keystroke delay and other presentation details which affect this are tunable to the user's personal preference.
This is not likely to cause much confusion in practice. I don't think this is something we'll be working to address any time soon. We might be able to do something with different spacing for F-keys and other special keys but I don't see it as a priority relative to other things we could spend time on.


first prototype of webdb class added

Creation and parsing of logs into mySQL database, using test credentials

Good start. However:
* Never put usernames and passwords in a git repo. They should be read from a configuration file that is explicitly _not_ in the repo.  This repo is public. You now need to change your username and password!

* The tests should go in a file called webdb_test.py and be in the tests directory.

* Generally, the test should be testing creating the _table_, not the database. The database should already exist. That way the test user only needs 'CREATE TABLE' privs, and not 'CREATE DATABASE' privs.

Want to give another try?

Those are just placeholder credentials at the moment.
I'll get started on the second prototype

Right, but don't even put in placeholder credentials. Here's what I did elsewhere:
https://github.com/summer-2020-interns/mailtools/blob/master/config.ini_demo
And here is how you would read the credentials from a config file:
https://github.com/summer-2020-interns/mailtools/blob/master/autoresponder/autoresponder.py#L70

got it, i'll implement a config file now

Right.  Another way to do it is you set the username and password in your .bashrc file and read them from environment variables.


Spread must be the final element of an element list

With the javascript below, I receive the error Spread must be the final element of an element list
let values = [
  5,
  3
];

Producer.create(window.session, ...values, session => {
  return this;
}

Have I missed a configuration option?
Thanks!

This issues shouldn't exist in current master, i will close this, but ping us up if it does happen with the latest commits

"Doh!"
My global JSCS was out of date, I was wondering why SublimeLinter wasn't showing the error but the cli jscs . was.
Thanks!


Resizing horizontally breaks the prompt

Open demo:

Run term.resize(term.cols - 2, term.rows) several times

The cursor will not go to the end of the line, the characters to the right are seemingly deleted. Pressing enter shows that they were just invisible on the UI:

When the horizontal size is changed, the terminal should wrap the prompt (ideally lines above the prompt too), just like when entering text into a narrow terminal:

@Tyriar does this still happen, after we merged #101?

@parisk yes, #101 only fixed resizing rows, this is resizing columns. Also I'll probably take a crack at fixing this one too if you want to assign to me.

It seems that GitHub won't let me assign this to you, but feel free to take this over. It would be amazing to have a PR for this.

Another note on this, the   characters at the end seem to get cut and never refreshed, meaning that scroll events on the rows that are cut short don't make it to the terminal.

Would stripping all trailing  s help?

@parisk the   are good I think, provided the character width problems are handled. The   and other characters if possible need to be restored.

This is still broken, right?

@waywaaard yes, the terminal should still work after resizing fine, it just truncates a chunk of the output.

Yeah, I mean the truncating. Is there a (hacky) way of fixing this for now?

No workaround, the characters are discarded on resize. The fix for this is to enable wrapping or to hang on to the lines and not display them.

I believe this is fixed after https://github.com/sourcelair/xterm.js/pull/616


chore(deploy): remove ansible scripts for install

These will just live in openshift-ansible from now on. There's enough
divergence that it's not worth trying to generate them from the same
chart we use for upstream.

LGTM


🐛 Fix JSON Schema for ValidationError at field loc

See #3790
Basically, Pydantic's schema for the loc field of the error detail is Union[str, int] not str for e.g. cases when the invalid data is at a particular index of an array:
See the type defined in Pydantic's source here:
https://github.com/samuelcolvin/pydantic/blob/5ccbdcb5904f35834300b01432a665c75dc02296/pydantic/error_wrappers.py#L12
The openapi.json schema for a ValidationError should match this.
This is particularly important for automated testing using https://schemathesis.readthedocs.io/en/stable/ because ValidationErrors that don't match the schema will lead to failing tests.
I've updated the validation_error_definition (h/t to @silversurfer34 for creating the issue and supplying the fixed schema 😄 ).
Also I had to update all the tests since the openapi.jsons are hardcoded in that.

Awesome, thanks @dconatha for the work and explanation! :nerd_face: :cake:
This will be available in FastAPI 0.75.2, released in a couple of hours. :rocket: