* https://github.com/jspecify/jspecify-reference-checker/blob/61aafa4ae52594830cfc2d61c8b113009dbdb045/src/main/java/com/google/jspecify/nullness/NullSpecTransfer.java#L789
   * and https://github.com/jspecify/jspecify/issues/490.
   *
   * (Perhaps it should also have required that its cause was a RuntimeException. However, that

  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see

Therefore, it lists pre-conditions and actions that should be performed to
resolve and fix a reported vulnerability.

## Vulnerability Management Process

The vulnerability management process requires that the vulnerability report
contains the following information:

- The project / component that contains the reported vulnerability.
- A description of the vulnerability. In particular, the type of the

   *     begins. Consider replacing code that creates {@link ListenableFuture}s of closeable types,
   *     including those that pass them to this method, with {@link #submit(ClosingCallable,
   *     Executor)} in order to ensure that resources do not leak. Or, to start a pipeline with a
   *     {@link ListenableFuture} that doesn't create values that should be closed, use {@link
   *     ClosingFuture#from}.
   */

  /*
   * Ideally, this class would have exposed only constructors that require a non-null cause. See
   * https://github.com/jspecify/jspecify-reference-checker/blob/61aafa4ae52594830cfc2d61c8b113009dbdb045/src/main/java/com/google/jspecify/nullness/NullSpecTransfer.java#L789
   * and https://github.com/jspecify/jspecify/issues/490.
   *
   * (That would also have ensured that its cause was always an Error, rather than possibly another

    -->
    <module name="ModifierOrder" />

    <!-- Checks that we don't include modifier where they are implied. For
      example, this does not allow interface methods to be declared public
      because they are *always* public. -->
    <module name="RedundantModifier" />
    <!-- Checks that all java files have a package declaration and that it
      lines up with the directory structure. -->

```JSON
{"item_id":3}
```

/// check

Notice that the value your function received (and returned) is `3`, as a Python `int`, not a string `"3"`.

So, with that type declaration, **FastAPI** gives you automatic request <dfn title="converting the string that comes from an HTTP request into Python data">"parsing"</dfn>.

///

## Data validation { #data-validation }

       * more information, see the comments in that class.
       *
       * We already know that that's how it behaves, and subclasses of Converter can't change that
       * behavior. So there's no sense in making all subclass authors exclude the method from any
       * NullPointerTester tests that they have.
       */
      ignoredMembers.add(Converter.class.getMethod("apply", Object.class));

 *
 * Implementations authenticate by returning a follow-up request that includes an authorization
 * header, or they may decline the challenge by returning null. In this case the unauthenticated
 * response will be returned to the caller that triggered it.
 *
 * Implementations should check if the initial request already included an attempt to
 * authenticate. If so it is likely that further attempts will not be useful and the authenticator

  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same
    Java package; see