except.txt lists features that may disappear without breaking true
compatibility.

Starting with go1.19.txt, each API feature line must end in "#nnnnn"
giving the GitHub issue number of the proposal issue that accepted
the new API. This helps with our end-of-cycle audit of new APIs.
The same requirement applies to next/* (described below), which will
become a go1.XX.txt for XX >= 19.

If your CL addresses an accepted proposal, mention the proposal issue number in
your release note in the form `/issue/NUMBER`. A link to the issue in the text
will have this form (see below). If you don't want to mention the issue in the
text, add it as a comment:
```
<!-- go.dev/issue/12345 -->
```
If an accepted proposal is mentioned in a CL but not in the release notes, it will be

var errSftpPublicKeyWithoutCert = errors.New("public key authentication without certificate is not accepted")

// error returned in SFTP when user used certificate which does not contain principal(s)
var errSftpCertWithoutPrincipals = errors.New("certificates without principal(s) are not accepted")

// error returned when group name contains reserved characters

testing/architecture-test                   @gradle/bt-architecture-council

# These files change frequently, and changes to them don't need to automatically alert the architecture council
testing/architecture-test/src/changes/accepted-changes/accepted-public-api-changes.json
testing/architecture-test/src/changes/archunit-store/internal-api-nullability.txt

# Core automation platform (core/configuration)
platforms/core-configuration/               @gradle/bt-cortex

    id: generics-proposal
    attributes:
      label: Is this about generics?
      description: If so, how does this relate to the accepted design and other generics proposals?
      placeholder: |
       Yes or No

       If yes, 
        1. how does this relate to the accepted design and other generics proposals?

    validations:
      required: true

  - type: textarea
    id: proposal
    attributes:

* Daten verarbeiten:
    * Angenommen, Sie erhalten eine Datei, die einen langsamen Prozess durchlaufen muss. Sie können als Response „Accepted“ (HTTP 202) zurückgeben und die Datei im Hintergrund verarbeiten.

## `BackgroundTasks` verwenden

* Procesamiento de datos:
  * Por ejemplo, supongamos que recibes un archivo que debe pasar por un proceso lento, puedes devolver un response de "Accepted" (HTTP 202) y procesar el archivo en segundo plano.

## Usando `BackgroundTasks`

Primero, importa `BackgroundTasks` y define un parámetro en tu *path operation function* con una declaración de tipo de `BackgroundTasks`:

Or you could also pin it with:

```txt
fastapi[standard]>=0.112.0,<0.113.0
```

that would mean that you would use the versions `0.112.0` or above, but less than `0.113.0`, for example, a version `0.112.2` would still be accepted.

If you use any other tool to manage your installations, like `uv`, Poetry, Pipenv, or others, they all have a way that you can use to define specific versions for your packages.

## Available versions { #available-versions }

* Обробка даних:
    * Наприклад, якщо отримано файл, який потрібно обробити довготривалим процесом, можна повернути відповідь "Accepted" ("Прийнято", HTTP 202) і виконати обробку файлу у фоні.

## Використання `BackgroundTasks`

* Traiter des données :
    * Par exemple, si vous recevez un fichier qui doit passer par un traitement lent, vous pouvez retourner une réponse «Accepted» (HTTP 202) puis faire le traitement en arrière-plan.


## Utiliser `BackgroundTasks`