text:
Nullable return on a not-null relationship one-to-many during update & fetch action

Bug description
We are working with a one-to-many relationship Invoice-Payments and when performing a query on Payment, fetching the related Invoice should never be nullish.
How to reproduce
Performing an update and fetch on Payment returns Promise<(Invoice & { Payment: Payment[] }) | null> type.
Expected behavior
Because a Payment is always related to an Invoice, return type should be Promise<Invoice & { Payment: Payment[] }>
Prisma information

Schema
model Payment {
  id           Int           @default(autoincrement()) @id
  status       paymentstatus
  invoice      Int
  Invoice      Invoice       @relation(fields: [invoice], references: [id])
}
model Invoice {
  id          Int           @default(autoincrement()) @id
  status      invoicestatus
  Payment     Payment[]
}

Client query
// invoice: Promise<(Invoice & { Payment: Payment[] }) | null>
const invoice = client.payment
    .update({
      where: {
        id: paymentId
      },
      data: {
        status: "payment:ok",
        Invoice: {
          update: {
            status: "invoice:ok"
          }
        }
      }
    })
    .Invoice({
      include: {
        Payment: true
      }
    });

Current workaround
  const paymentWithRelatedInvoice = await database.payment.update({
    where: {
      id: paymentId
    },
    data: {
      status: "payment:ok",
      Invoice: {
        update: {
          status: "invoice:ok"
        }
      }
    },
    include: {
      Invoice: {
        include: {
          Payment: true
        }
      }
    }
  });

  // invoice: Invoice & { Payment: Payment[] }
  const { Invoice: invoice } = paymentWithRelatedInvoice;

Environment & setup

OS: Mac OS
Database: PostgreSQL
Node.js version: 12.14.1
Prisma version:

@prisma/cli          : 2.5.1
Current platform     : darwin
Query Engine         : query-engine c88925ce44a9b89b4351aec85ba6a28979d2658e (at node_modules/@prisma/cli/query-engine-darwin)
Migration Engine     : migration-engine-cli c88925ce44a9b89b4351aec85ba6a28979d2658e (at node_modules/@prisma/cli/migration-engine-darwin)
Introspection Engine : introspection-core c88925ce44a9b89b4351aec85ba6a28979d2658e (at node_modules/@prisma/cli/introspection-engine-darwin)
Format Binary        : prisma-fmt c88925ce44a9b89b4351aec85ba6a28979d2658e (at node_modules/@prisma/cli/prisma-fmt-darwin)
Studio               : 0.261.0

I am going to close this as its been 3 months now and there is no activity here.
Please reply if you want us to take another look.

I am going to close this as its been 3 months now and there is no activity here.
Please reply if you want us to take another look.

repo: prisma/prisma-client-js


text:
orderBy using self-referential relation in a nested relation fails with "table name "TableName" specified more than once"

Bug description
A findMany query that attempts to orderBy a self-referntial relation nested inside another relation in a ConnectorError with message:
table name \"TableName\" specified more than once

Here's an example generated query:
'SELECT "public"."FulfillmentOrder"."orderId", "public"."FulfillmentOrder"."preSaleId", "public"."FulfillmentOrder"."preSaleOrderId", "public"."FulfillmentOrder"."distributorFee", "public"."FulfillmentOrder"."platformFee", "public"."FulfillmentOrder"."platformFeeOverride", "public"."FulfillmentOrder"."missingPlatformFeeConfiguration", "public"."FulfillmentOrder"."createdAt", "public"."FulfillmentOrder"."updatedAt" FROM "public"."FulfillmentOrder" LEFT JOIN "public"."Order" AS "orderby_0_Order" ON ("public"."FulfillmentOrder"."orderId" = "orderby_0_Order"."id") LEFT JOIN "public"."Order" AS "orderby_0_Order" ON ("orderby_0_Order"."producerPurchaseOrderId" = "orderby_0_Order"."id") WHERE ("public"."FulfillmentOrder"."orderId") IN (SELECT "t0"."orderId" FROM "public"."FulfillmentOrder" AS "t0" INNER JOIN "public"."Order" AS "j0" ON ("j0"."id") = ("t0"."orderId") WHERE ("j0"."type" = $1 AND "j0"."cancelledAt" IS NULL AND "j0"."deliveredAt" IS NULL AND "j0"."placedOn" >= $2 AND ("j0"."id") IN (SELECT "t1"."id" FROM "public"."Order" AS "t1" INNER JOIN "public"."Order" AS "j1" ON ("j1"."id") = ("t1"."producerPurchaseOrderId") WHERE (("j1"."id") IN (SELECT "t2"."id" FROM "public"."Order" AS "t2" INNER JOIN "public"."TrackingInformation" AS "j2" ON ("j2"."orderId") = ("t2"."id") WHERE ("j2"."deliveredAt" IS NOT NULL AND "t2"."id" IS NOT NULL)) AND "t1"."id" IS NOT NULL)) AND "t0"."orderId" IS NOT NULL)) ORDER BY "orderby_0_Order"."placedOn" ASC LIMIT $3 OFFSET $4',

You can see that the same alias orderby_0_Order is used in to label two joins.
How to reproduce
With a schema that includes a self-referential relation:
model FulfillmentOrder {
  orderId Int
  order Order @relation(fields: [orderId])
}

model Order {
  field Int?
  producerPurchaseOrderId Int?
  producerPurchaseOrder   Order?  @relation(name: "ProducerPurchaseOrder", fields: [producerPurchaseOrderId], references: [id])
  orders                  Order[] @relation(name: "ProducerPurchaseOrder")
}

Running a query like:
prisma.fulfillmentOrder.findMany({
  orderBy: {
    order: {
      producerPurchaseOrder: {
        createdAt: "asc"
      }
    }
  }
})

will fail.
However, if there's not an initial nested it succeeds:
prisma.order.findMany({
  where: {
    producerPurchaseOrder: {
      createdAt: 'asc'
     }
   }
});

Expected behavior
The first query returns the FulfillmentOrders sorted by the Order -> ProducerPurchaseOrder -> createdAt asc.
Prisma information
prisma@3.10.0
Environment & setup

OS: MacOS
Database: Postgres
Node.js version: 14.19

Prisma Version
prisma                  : 3.10.0
@prisma/client          : 3.10.0
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 73e60b76d394f8d37d8ebd1f8918c79029f0db86
Studio                  : 0.458.0
Preview Features        : interactiveTransactions

Internal discussion https://prisma-company.slack.com/archives/C040N0UADF0/p1662489999108879

source: gharchive/issue

authors: adaddeo millsp

repo: prisma/prisma

license_type: permissive

license_source: github-api


text:
Support for TiDB

Problem

This issue is there to track interest and use cases for supporting TiDB with Prisma.

TiDB (/’taɪdiːbi:/, "Ti" stands for Titanium) is an open-source NewSQL database that supports Hybrid Transactional and Analytical Processing (HTAP) workloads. It is MySQL compatible and features horizontal scalability, strong consistency, and high availability. The goal of TiDB is to provide users with a one-stop database solution that covers OLTP (Online Transactional Processing), OLAP (Online Analytical Processing), and HTAP services. TiDB is suitable for various use cases that require high availability and strong consistency with large-scale data.

GitHub Repo: pingcap/tidb (with 🌟 34.2k stars and 🍴5.5k forks)
TiDB Cloud (provide free cluster for developer tier)
Document about MySQL Compatibility

Suggested solution

[ ] Pass integration tests of MySQL in this monorepo (https://github.com/prisma/prisma/pull/14631)
[ ] Pass tests in the prisma-engines repo (https://github.com/prisma/prisma-engines/pull/3308)
[ ] Guidelines for integrating TiDB with Prisma
[ ] Add custom provider to support the advanced features (Such as AUTO_RANDOM)

✅ Also add Prisma Integration Tests to TiDB CI pipeline.


text:
GroupBy with relation fields

Problem
https://github.com/prisma/prisma/issues/7472
Suggested solution
https://github.com/prisma/prisma/issues/7472#issuecomment-855592677

Hi @AaravShah042!  We already have an open feature request for this: #16243. I am going to close this issue as duplicate, let's continue discussion there.


text:
Query Engine uses schema.prisma connection string for initial connection, even when datasources.db is set in Prisma Client constructor

Schema:
datasource postgresql {
  provider = "postgresql"
  url      = "postgresql://foo"
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id      Int     @default(autoincrement()) @id
  email   String  @unique
  name    String?
  role    String?
  storeId Int?
}

model Product {
  id          Int     @default(autoincrement()) @id
  handle      String  @unique
  name        String?
  description String?
  price       Int?
}

Code:
const express = require('express')
const app = express()
const port = process.env.PORT || 3000;

// const path = require('path')

const { PrismaClient } = require('@prisma/client')

const prismaPgPlain = new PrismaClient({
  log: ['query', 'info', 'warn'],
  datasources: {
    db: "postgresql://###connectiona###",
  },
  //forceTransactions: true,
})

app.get('/api/pg-plain', async (req, res) => {
  const products = await prismaPgPlain.product.findMany({ first: 4 })
  res.send(JSON.stringify(products))
})

app.listen(port, () =>
  console.log(`Example app listening at http://localhost:${port}`),
)

This means that PrismaClient should use the supplied connection string only, not what is visible in the schema.

But if I run this server and try to call /api/pg-plain, I get the following error message:
PS C:\Users\Jan\Documents\throwaway\divyPgBouncer> yarn start
yarn run v1.22.0
warning package.json: No license field
$ node index.js
Example app listening at http://localhost:3000
prisma:info  Starting a postgresql pool with 9 connections.
prisma:info  Started http server on 127.0.0.1:50797
(node:23612) UnhandledPromiseRejectionWarning: Error:
Invalid `prismaPgBouncerPlain.product.findMany()` invocation in
C:\Users\Jan\Documents\throwaway\divyPgBouncer\index.js:31:55

  27   //forceTransactions: true,
  28 })
  29
  30 app.get('/api/pgbouncer-plain', async (req,[object Object], res) => {
→ 31   const products = await prismaPgBouncerPlain.product.findMany(Can't reach database server at `foo`:`5432`

Please make sure your database server is running at `foo`:`5432`.
    at PrismaClientFetcher.request (C:\Users\Jan\Documents\throwaway\divyPgBouncer\node_modules\@prisma\client\runtime\index.js:1:85866)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
(node:23612) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:23612) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This indicates to me that the initial server connection of the QE is probably made to the wrong server, which is very concerning and might lead to a lot of confusion.

This issue might be fully invalid, maybe datasources.db just does nothing. Investigating.


text:
Fixed values in relationship fields (for polymorphic relationships)

Problem
I am mapping to a database where I don't have control of the structure and is handled by another ORM specifically Illuminate in a laravel project, in Illuminate they have the concept of a "morph many" joins where the model name is used along side a model id to store a relationship
model SlideSetEntry {
  id Int @id @default(autoincrement()) @db.UnsignedInt
 ....

  @@map("slidesetentry")
}

model Note {
  id Int @id @default(autoincrement())
  notestableId Int @db.UnsignedInt @map("notestable_id")
  notestableType String @map("notestable_type")
 ...

  @@map("notes")
}

In Illuminate there is a n:m relationship between SlideSetEntry and Note where SlideSetEntry.id = Note.notestableId and Note.notestableType = "models\SlideSetEntry"
Right now there is  no way for me to express this relationship on SlideSetEntry so I need to manually join these at the query level.
Suggested solution
What I would like to do is this
model SlideSetEntry {
  id  Int @id @default(autoincrement()) @db.UnsignedInt
 ....

  notes SlideSetEntryNote[]

  @@map("slidesetentry")
}

model Note {
  id Int @id @default(autoincrement())
  notestableId Int @db.UnsignedInt @map("notestable_id")
  notestableType  String  @map("notestable_type")
 ...

  @@map("notes")
}

model SlideSetEntryNote {
  id  Int @id @default(autoincrement())
  notestableId Int @db.UnsignedInt @map("notestable_id")
  notestableType String  @map("notestable_type")
 ...

  slideSetEntry SlideSetEntry @relation(fields: [notestableId, notestableType], references: [id, "models\SlideSetEntry"])

  @@map("notes")
}

I think that is pretty easy to understand, open to alternative ideas to support this usecase.

The kinds of polymorphic relationships are indeed not supported in Prisma yet.
Is this the one you refer to above? https://laravel.com/docs/8.x/eloquent-relationships#many-to-many-polymorphic-relations
Can you maybe share the SQL that Eloquent creates/requires for this setup? Maybe even with a few simple example entries?

Duplicate of #2505 ?

authors: RobertSandiford janpio micahnz


text:
feat(project): add --project for Prisma definition file selection

Fixes https://github.com/prisma/prisma/issues/3140

Closing in favor of https://github.com/prisma/prisma/pull/4079

source: gharchive/pull-request


text:
generate: "Error: Schema parsing --- thread 'main' has overflowed its stack"

$ prisma2 generate
(node:21024) ExperimentalWarning: The fs.promises API is experimental
Error: Schema parsing
thread 'main' has overflowed its stack
error Command failed with exit code 1.

Seems to be Windows related and related to Rust it's stack size limit which is 1MB on Windows;  (that's what I've found on the interwebs)
Running it in Docker seems to fix it since that's unix, but then when starting the project from Windows CLI it complains about not finding the windows query engine since the generate was done in unix 🤦♂
Happened after adding a new model to my prisma-schema, probably increased the necessary stack_size with that causing it to error.

Ok, we have a plan: On Monday we will see if our current theory of problem and solution are correct, and if so provide an adapted binary for me and you to test out.

Great stuff, how do I get it and where do I put it?

I do not know that yet, as it is not Monday yet. I will update this issue then.

@janpio Friendly ping, any updates?

We added this to the current sprint. Right now I do not know yet when we will have a new build with these problems fixed, sorry. We will update this issue as soon as we do.

For people running into the same issue. You can run the project in docker and run generate command from there.
To start a container from within your current working folder in powershell:
docker run -p 8080:8080  -it -v ${PWD}:/home/dev keymetrics/pm2:10-jessie /bin/bash

or in bash
docker run -p 8080:8080  -it -v /${PWD}:/home/dev keymetrics/pm2:10-jessie /bin/bash

This launches a bash shell inside the container, you can then run any commands that you used to run from the folder /home/dev
For example:
cd home/dev
yarn generate (-> prisma2 generate)
yarn seed (-> ts-node prisma/seed)
yarn dev (-> cross-env NODE_ENV=development nodemon)

To reproduce this on Windows without the CLI, but with the Query Engine directly:

Create a schema.prisma file by copy pasting this: https://github.com/prisma/prisma2/issues/1496#issuecomment-580868816 (in my case: C:\Users\Jan\Documents\throwaway\1496\schema.prisma)
Install prisma2 from npm
Find the Query Engine binary path (in my case: C:\ProgramData\nvm\v12.6.0\node_modules\prisma2\query-engine-windows.exe)
Set a bunch of ENV vars:

set DEBUG=*
 set PRISMA_DML_PATH=C:\Users\Jan\Documents\throwaway\1496\schema.prisma

Run the following command to see the crash: C:\ProgramData\nvm\v12.6.0\node_modules\prisma2\query-engine-windows.exe cli --dmmf

Output looks like this:
C:\Users\Jan\Documents\throwaway\1496
λ C:\ProgramData\nvm\v12.6.0\node_modules\prisma2\query-engine-windows.exe cli --dmmf

thread 'main' has overflowed its stack

I have a convenient way to reproduce this on my machine, working on a fix now.

I have a fix: https://github.com/prisma/prisma-engine/pull/454
With the schema posted above, DMMF rendering overflowed a 1MB stack, with these changes it doesn't overflow a 400kb stack.

Once this is merged, it should be on alpha pretty fast for you to test.

This is now merged and released in the current alpha - and it works:

C:\Users\Jan\Documents\throwaway\1496
λ prisma2 generate
Error: Schema parsing

thread 'main' has overflowed its stack

C:\Users\Jan\Documents\throwaway\1496
λ npx prisma2@alpha generate
Error: Oops! Photon has been renamed to Prisma Client. Please make the following adjustments:
  1. Rename provider = "photonjs" to provider = "prisma-client-js" in your schema.prisma file.
  2. Replace your package.json's @prisma/photon dependency to @prisma/client
  3. Replace import { Photon } from '@prisma/photon' with import { PrismaClient } from '@prisma/client' in your code.
  4. Run prisma2 generate again.

Instead of the stackoverflow I get a proper error message that I should update my schema.prisma, and if I do that it actually works:
C:\Users\Jan\Documents\throwaway\1496
λ npx prisma2@alpha generate
Generated Prisma Client to .\node_modules\@prisma\client
Done in 1.22s

Can you confirm this works for you as well @maartenraes? Just running npx prisma2@alpha generate should be enough to test before updating your project to the alpha.

@janpio just came around to updating to the newest preview and fix all breaking changes.
Then upgrading to alpha indeed solves the issue.
I would leave the issue open till it's in the preview22 release?

Nah we usually close issues when they are fixed in the codebase as the changes become available in alpha. But yes, this will be included in preview22 probably later this week.

authors: janpio maartenraes tomhoule


text:
How do i run raw GraphQL

Can we query GraphQL in Prisma 2? and how?

Hi,
I am assuming that you are referring to the GraphQL API which was exposed by Prisma 1.
We are not exposing GraphQL API this time as it is an implementation detail. It is used as a wire protocol in Prisma 1 and we have removed it Prisma 2 and have adopted a newer wire protocol(which still currently uses GraphQL internally but we may switch it in the future with something like gRPC) between Photon and query engine.
Photon is meant to be used as ORM. You can build a GraphQL API using it. Here is an example: https://github.com/prisma/photonjs/tree/master/examples/typescript/graphql
We have also written a blog post to clear this confusion out: https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/

Ok. Thank you for the clarification

We are closing this issue, please feel free to re-open a new issue if you think that the concern was not addressed.

link is dead. can you update it for future readers?
https://github.com/prisma/photonjs/tree/master/examples/typescript/graphql

@softmarshmallow The link has moved to https://github.com/prisma/prisma-examples/tree/prisma2/typescript/graphql

authors: divyenduz emahuni pantharshit00 softmarshmallow


text:
feat: add styled Restrict page

complete #4
preview:
https://www.loom.com/share/a83dd5e4ae8641b2a69ee0e3d6c64924?sid=06799fcb-a2ab-4615-abee-c57cbb3dfc18

@anshmourya Apologies for the delay! I was travelling. This is so beautiful !Thank you for the contribution :) Guess it's now ready to be taken live!

authors: anshmourya pritipsingh

repo: pritipsingh/The-Productive-Champion

license: MIT


text:
Cancelling a render rendering to "it" closes blender

When rendeman is set to render to it, and when cancelling the render in it (By either pressing esc or pressing the button), it crashes blender. This applies for ipr and final renders. However, cancelling the render from the blender window doesn't cause this.
blender_debug_output.txt

R56005 {SEVERE}  Renderer completing shutdown request. (System Error: Invalid argument)
Error: Not freed memory blocks: 167255, total unfreed memory 65.522133 MB

This is a known issue and it's mentioned in the docs.
https://rmanwiki.pixar.com/display/RFB24/RenderMan+for+Blender+24.0
You'll need to cancel the render in Blender.

The docs seem to not load for me, is the website down or something?

repo: prman-pixar/RenderManForBlender

license: mit

license_source: bigquery


text:
gracefully report variables whose statistical types are not known to cgpm

CGPM will fail gracelessly if it encounters a statistical type not in _DEFAULT_DIST.

Fixed in 7520005bb3bda14bd904d31374e878952ea476b9.

repo: probcomp/bayeslite


text:
Speed estimation of CLI progress bars seems wrong

[dirbaio@mars firmware]$ probe-rs-cli download --format hex --chip nrf52840 softdevice/s140_v7.2.0.hex --speed 30000
     Erasing sectors ✔ [00:00:03] [#####################################################################################################] 156.00KiB/156.00KiB @ 45.02KiB/s (eta 0s )
 Programming pages   ✔ [00:00:01] [#####################################################################################################] 156.00KiB/156.00KiB @ 25.14KiB/s (eta 0s )
    Finished in 5.332s

The first bar takes 3s, and the speed estimate says 45.02KiB/s. The second takes 1s, so it's faster, but the speed estimate is 25.14KiB/s which is slower...

Is this still an issue?

I think the @ was always just a rolling speed and not the average, so this is actually correct althought counter-intuitive I believe. I wonder if we can make it more intuitive.

I do not have an nrf52840 but after a bunch of trials I haven't been able to repro, so I have to assume this has been fixed. Please reopen if you encounter the issue again.

authors: Dirbaio Yatekii bugadani

repo: probe-rs/probe-rs


text:
Extend timeout by the time the target spent halted

When using semihosting to print assert failures, tests may time out during printing. This PR should help with that, by extending the timeout.

I guess I should test this first, but I'd like to hear some feedback about the idea itself.


text:
Suggestion: make desktop integration install icon file to ~/.local/share/icons

Hi,
I decided to use an Atom AppImage to provide me with the Atom text editor in a Gentoo Linux VM. Why not install it from source using Gentoo's Portage package manager? Because it conflicts with core components of the KDE Plasma 5 desktop environment. Now I am mentioning this because I noticed as soon as I rebooted this VM the Atom desktop config file generated by the AppImage was no longer finding the Atom icon. This is because it pointed to /tmp/.mount*/DirIcon where the wildcard operator * is of course replaced with the exact mount location of the AppImage. I am here to suggest that maybe your desktop integration should install the icon in the top level directory of the AppImage to ~/.local/share/icons (which does not require root privileges so should be ideal) and the desktop config file should point to this icon instead of to /tmp/.mount*/DirIcon.
Thanks for your time,
Brenton

/tmp/.mount*/DirIcon clearly seems to be a bug. Can you see if https://github.com/probonopd/AppImageKit/pull/292 would improve this?

Gives this desktop config file:
Type=Application
Name=Atom
Icon=appimagekit-atom
Exec="/home/fusion809/GitHub/mine/packaging/AppImages/recipes/meta/atom/out/Atom-1.12.6.glibc2.14-x86_64.AppImage" %U
Categories=Development;TextEditor;GTK;
Comment=The hackable text editor for the 21st century.
X-Desktop-File-Install-Version=0.22
X-AppImage-Comment=Generated by ./bin//atom.wrapper
TryExec=/home/fusion809/GitHub/mine/packaging/AppImages/recipes/meta/atom/out/Atom-1.12.6.glibc2.14-x86_64.AppImage

and FYI it doesn't install an icon called appimagekit-atom in ~/.local/share/icons.

I've found a way around it. Download the source code tarball and run python setup.py install --prefix=/AppDir/usr in it.

I've found a way around it. Download the source code tarball and run python setup.py install --prefix=/AppDir/usr in it.

That solves what, exactly? ;-)

Oops wrong issue :P

Is this solved by https://github.com/probonopd/AppImageKit/pull/292?

Nope, didn't you see this earlier comment?

repo: probonopd/AppImages


text:
Add more tests for our comment check logic

We are currently searching a set of strings in the comment body to identify whether the comment author is wanting to claim the issue.
Since we are planning to use various heuristics for the same, it's good to have tests early on to ensure we don't break existing cases, and it also provides us with goals for our bot.

Once we have a big list of comments signatures to support, we can come up with a better way to implement it, be it nlp or simple keyword search.

repo: probot/first-timers-only-app

license: ISC


text:
Fix editor 'reset theme' button

Must be leftover from smth. This one works. Same values for everything as the default.

fixed independently

authors: Maildropfolder prodzpod

repo: prodzpod/witness


text:
Во все ручки добавить скоупы, которые они требуют

В ручках (файлы в папке routes) есть зависимость от UnionAuth. Там есть поле scopes в конструкторе
Надо записать эти scopes в докстринг так, чтобы их было видно из Swagger
Референс: https://github.com/profcomff/auth-api/blob/b17d6a5a258bf18d0f5a5ecb26b0e4f41d25baa7/auth_backend/routes/user.py#L33

@DaymasS все понятно по постановке?

repo: profcomff/userdata-api


text:
Update fs2-core to 3.2.6

Updates co.fs2:fs2-core from 3.2.5 to 3.2.6.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "co.fs2", artifactId = "fs2-core" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #23.

repo: profunktor/neutron


text:
🛑 Multi Hardware is down

In 86215dc, Multi Hardware (https://www.multi-hardware.com/retrogami) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Multi Hardware is back up in 78e1f7d after 17 minutes.

repo: proger-su/upptime


text:
Docker has to be updated by adding the data model directory

Describe the bug
To run the TC_AccessChecker.py test, need to include the XML files from the data model directory. But it's not available in current docker.
So the data model from ~/certification-tool/backend/test_collections/matter/sdk_tests/sdk_checkout/python_testing$ has to be added inside the docker root@ubuntu:~/python_testing#.
Steps to reproduce the behavior

Build the docker:  docker run -v /var/credentials:/credentials -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v /launch_dir --privileged --network host -it connectedhomeip/chip-cert-bins:9f6d627e0262e1d023986291948bb4e845be803e
Change the directory to python_testing

Environment
connectedhomeip/chip-cert-bins:9f6d627e0262e1d023986291948bb4e845be803e

Hi @Survensa, you can do that by the volume mapping to your command: -v /home/ubuntu/certification-tool/backend/test_collections/matter/sdk_tests/sdk_checkout/python_testing/data_model:/root/python_testing/data_model to your command
$ docker run -v /var/credentials:/credentials -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v /home/ubuntu/certification-tool/backend/test_collections/matter/sdk_tests/sdk_checkout/python_testing/data_model:/root/python_testing/data_model -v /launch_dir --privileged --network host -it connectedhomeip/chip-cert-bins:9f6d627e0262e1d023986291948bb4e845be803e
root@vm-matter-x64:~# cd python_testing/
root@vm-matter-x64:~/python_testing# ls
MinimalRepresentation.py      TC_DeviceConformance.py      TC_MWOM_1_2.py         TC_RVCRUNM_2_2.py       TC_VALCC_4_5.py
TC_ACE_1_2.py                 TC_EEM_2_1.py                TC_OPCREDS_3_1.py      TC_SC_3_6.py            TC_pics_checker.py
TC_ACE_1_3.py                 TC_EEM_2_2.py                TC_OPSTATE_1_1.py      TC_TIMESYNC_2_1.py      TestBatchInvoke.py
TC_ACE_1_4.py                 TC_EEM_2_3.py                TC_OPSTATE_2_1.py      TC_TIMESYNC_2_10.py     TestCommissioningTimeSync.py
TC_ACE_1_5.py                 TC_EEM_2_4.py                TC_OPSTATE_2_2.py      TC_TIMESYNC_2_11.py     TestConformanceSupport.py
TC_ACL_2_2.py                 TC_EEM_2_5.py                TC_OPSTATE_2_3.py      TC_TIMESYNC_2_12.py     TestGroupTableReports.py
TC_AccessChecker.py           TC_EEVSE_2_2.py              TC_OPSTATE_2_4.py      TC_TIMESYNC_2_13.py     TestMatterTestingSupport.py
TC_BOOLCFG_2_1.py             TC_EEVSE_2_4.py              TC_OPSTATE_2_5.py      TC_TIMESYNC_2_2.py      TestSpecParsingSupport.py
TC_BOOLCFG_3_1.py             TC_EEVSE_2_5.py              TC_OVENOPSTATE_1_1.py  TC_TIMESYNC_2_4.py      TestTimeSyncTrustedTimeSource.py
TC_BOOLCFG_4_1.py             TC_EEVSE_Utils.py            TC_OVENOPSTATE_2_1.py  TC_TIMESYNC_2_5.py      basic_composition_support.py
TC_BOOLCFG_4_2.py             TC_EPM_2_1.py                TC_OVENOPSTATE_2_2.py  TC_TIMESYNC_2_6.py      conformance_support.py
TC_BOOLCFG_4_3.py             TC_EPM_2_2.py                TC_OVENOPSTATE_2_3.py  TC_TIMESYNC_2_7.py      data_model
TC_BOOLCFG_4_4.py             TC_EnergyReporting_Utils.py  TC_OVENOPSTATE_2_4.py  TC_TIMESYNC_2_8.py      drlk_2_x_common.py
TC_BOOLCFG_5_1.py             TC_FAN_3_1.py                TC_OVENOPSTATE_2_5.py  TC_TIMESYNC_2_9.py      global_attribute_ids.py
TC_BOOLCFG_5_2.py             TC_FAN_3_2.py                TC_OpstateCommon.py    TC_TIMESYNC_3_1.py      hello_external_runner.py
TC_CGEN_2_4.py                TC_FAN_3_3.py                TC_PWRTL_2_1.py        TC_TestEventTrigger.py  hello_test.py
TC_CNET_4_4.py                TC_FAN_3_4.py                TC_RR_1_1.py           TC_VALCC_2_1.py         matter_testing_support.py
TC_DA_1_2.py                  TC_FAN_3_5.py                TC_RVCCLEANM_1_2.py    TC_VALCC_3_1.py         mdns_discovery
TC_DA_1_5.py                  TC_ICDM_2_1.py               TC_RVCCLEANM_2_1.py    TC_VALCC_3_2.py         requirements.txt
TC_DA_1_7.py                  TC_IDM_1_2.py                TC_RVCCLEANM_2_2.py    TC_VALCC_3_3.py         spec_parsing_support.py
TC_DGGEN_2_4.py               TC_IDM_1_4.py                TC_RVCOPSTATE_2_1.py   TC_VALCC_3_4.py         taglist_and_topology_test_support.py
TC_DRLK_2_12.py               TC_IDM_4_2.py                TC_RVCOPSTATE_2_3.py   TC_VALCC_4_1.py         test_testing
TC_DRLK_2_2.py                TC_MWOCTRL_2_2.py            TC_RVCOPSTATE_2_4.py   TC_VALCC_4_2.py
TC_DRLK_2_3.py                TC_MWOCTRL_2_3.py            TC_RVCRUNM_1_2.py      TC_VALCC_4_3.py
TC_DeviceBasicComposition.py  TC_MWOCTRL_2_4.py            TC_RVCRUNM_2_1.py      TC_VALCC_4_4.py
root@vm-matter-x64:~/python_testing# cd data_model/
root@vm-matter-x64:~/python_testing/data_model# ls
README.md  clusters  device_types  scraper_version  spec_sha

Actually, I believe you'll need to add the following mapping: -v /home/ubuntu/certification-tool/backend/test_collections/matter/sdk_tests/sdk_checkout/python_testing:/root/python_testing.
Then, to run the tests, you'll have to navigate to python_testing/scripts/sdk to find the scripts.

This mapping solution should be ok for this release. But, for the next one, we should update the chip-cert-bins Dockerfile to include the data model files in the SDK image, instead of copying the files to TH backend and then mapping the volume during the test execution, like it's done today.

Opened the PR on the SDK repo: https://github.com/project-chip/connectedhomeip/pull/32361

Related SDK PR: https://github.com/project-chip/connectedhomeip/pull/34481

authors: Survensa ccruzagralopes

repo: project-chip/certification-tool


text:
Update AddNOC to follow final error handling spec text

Problem
In https://github.com/CHIP-Specifications/connectedhomeip-spec/pull/5231, error handling got normalized to follow reality. The updates need to be taken in once landed in spec. This was a Must-Fix 1.0 spec issue
Proposed Solution

Rename MissingAdminNode enum value to InvalidAdminSubject
Rename CaseAdminNode command field to CaseAdminSubject
Remove MissingIpk enum value

@cjandhyala @tcarmelveilleux @bzbarsky-apple  - is this actually a cert-blocker?
The way I read it, these are enum value renames ... do these enum values show up in cert tests? they sound internal to me, however I am not familiar with them.

Cert Blocker Review: @cjandhyala is updating the test plan to fully cover the test, which will make this a cert blocker.

@andy31415 These are spec-defined enums; they are not internal, but sent on the wire.  And it's not just renames, it's also which is returned when.

authors: andy31415 bzbarsky-apple tcarmelveilleux woody-apple

repo: project-chip/connectedhomeip


text:
Add new function signature for params

Problem
Currently there is no way to pass in certain parameters in the CHIP.framework API such as timeWrite and timedInteractionTimeoutMs.

Fixes #16252

Change overview

Adds new functions to allow passing in timedInteractionTimeoutMs and timeWrite.

Testing

Generated Code
Compiled
Ran a chip-tool-darwin test that does read, write and commands (legacy).

Fast-tracking Darwin-specific changes.


text:
Add COUNTOF in src/app/type_stubs.h and use it in the door lock cluster

Problem
This PR add the COUNTOF macro as define in #2499...
Summary of Changes

Add COUNTOF and use it in the door lock cluster

Fixes #2499

I removed the COUNTOF occurrences and uses ArraySize instead.
There are a few more changes since I convert the door-lock-cluster/*.c files to .cpp in the process.


text:
Add more debug for failing tests, fix small bug.

Problem
If this test fails, it's hard to debug.
Change overview
debugging info added. Also fixing a small bug - currently only one call is added, so this bug does not affect current tests.
Testing
Forced test failure, saw print.

@saurabhst @Damian-Nordic?

authors: cecille woody-apple


text:
ci(deps): bump minio test dependency

What type of PR is this?
cleanup

Which issue does this PR fix:
Cut off from #2532
What does this PR do / Why do we need it:
The new distribution version has some issues with old minio version. The ListObjectV2 returns Not Implemented
https://github.com/project-zot/zot/actions/runs/10026506554/job/27710895216?pr=2532#step:10:36
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:

Automation added to e2e:

Will this break upgrades or downgrades?
Does this PR introduce any user-facing change?:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@jkroepke just trying to understand what the scope of this PR is? Moving from stable releases to what looks like nightly releases sounds risky for us.

This PR moved from an outdated minio tag to a latest stable release.
The tag edge-cicd which is used in zot main is 3 years old. -> https://hub.docker.com/r/minio/minio/tags?page=&page_size=&ordering=&name=edge-cicd
RELEASE.2024-07-16T23-46-41Z is just a stable release. -> https://github.com/minio/minio/releases/tag/RELEASE.2024-07-16T23-46-41Z
The newer SDKs in distribution project are using S3 commands, which are not supported in 3 years old minio versions.

@jkroepke I see.
@peusebiu pls review this also.
LGTM

https://github.com/project-zot/zot/actions/runs/10074657923/job/27886068599
^ After the merge, the clustering test which uses minio is now slower??

project-zot/zot/actions/runs/10074657923/job/27886068599 ^ After the merge, the clustering test which uses minio is now slower??

The minio dependency was already included in that PR, but the warning didn't appear before.

authors: jkroepke rchincha

repo: project-zot/zot


text:
Fix typo

Signed-off-by: Tim Waugh twaugh@redhat.com

Fix for unreleased bug so no update to release notes draft.

repo: projectatomic/atomic-reactor


text:
Podman hangs after 'logout' in container with FUSE mount

Reported via IRC:
Podman will hang after 'logout' is run in a container that has a mounted FUSE filesystem. Exec will fail with exec failed: container_linux.go:348: starting container process caused "process_linux.go:86: executing setns process caused \"exit status 21\". Podman attach will not retrieve any output, though you can still type into the container's console.
Reproduce with:

Launch podman with pkexec podman run -it --priviledged=true --device=/dev/sdd1 --device=/dev/fuse debian su - (will probably need to modify the device line - maybe a loopback with a FUSE fs on it?)
In the container, run apt-get update; apt-get install exfat-fuse"; mount command: "cd /media; mkdir test; mount /dev/sdd1 test (again, device will likely not be /dev/sdd1 if you want to reproduce)
In the container, run logout

I suspect that a FUSE mount isn't actually necessary to reproduce this, and any mount will be sufficient, but I haven't verified that yet.

Correction, just using ordinary mounts doesn't seem to trigger this - logout causes the container to exit, and you can exec into the container and remove it with rm -f without issue (even with the mount not being unmounted before exiting)

@rhatdan Potentially - the container is privileged, but this could be a more general selinux issue.

The mount should be cleaned up since the mount namespace went away.

@mheon Do we still have this issue?

Closing. Feel free to re-open if the issue is still present or reoccurs.

authors: mheon rhatdan vrothberg

repo: projectatomic/libpod


text:
Revert "Dockerfile: remove inline comments"

This reverts commit 3dcdb1ff7d2360419c29c24e4032b7852aee3c26.
Upstream fix: https://github.com/docker/docker/pull/29006

LGTM

(LGTM)

authors: mtrmac rhatdan runcom

repo: projectatomic/skopeo