Pysoa

Latest version: v1.4.9

Safety actively analyzes 685838 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 7 of 25

0.64.0

-------------------
- [MINOR] Respawn crashed workers when running in forking mode

- By default, when running in forking mode, PySOA will respawn crashed workers.
- If a worker crashes 3 times in 15 seconds or 8 times in 60 seconds, PySOA will give up and stop respawning that worker.
- The new `--no-respawn` argument can disable this behavior if necessary.
- If all workers crash too many times and PySOA runs out of workers, it exits (this is basically the existing behavior, except for the above-described respawning).

- [MINOR] Add first functional tests and fix some bugs

- Create a functional test environment using Docker/Docker Compose and a simple shell script.
- Add an initial set of functional tests.
- Fix several bugs regarding signal handling in the `Server`, server process forking, and file-watching auto-reloader:

- If the server received several simultaneous signals (for example, if Ctrl+C is used), the signal handler could be invoked in parallel two or more times, resulting in, at best, forcefully-terminating the server and, at worst, that plus a bunch of concurrency errors. This is now fixed.
- If server process forking was enabled or the file-watching auto-reloader was enabled, non-Ctrl+C signals (such as those from Docker when running within a container) were suppressed, meaning the server would not stop.

- [PATCH] Re-organize all tests into `unit`, `integration`, and `functional` test modules

0.63.0

-------------------
- [MINOR] Support PyTest 5.0 with tests ensuring compliance

0.62.1

-------------------
- [PATCH] Fix misleading DeprecationWarning

0.62.0

-------------------
- [MINOR] Switch to using Conformity's class schemas (all existing configurations are backwards compatible and will continue to work).
- [MINOR] Deprecated `pysoa.server.settings.PolymorphicServerSettings` and `pysoa.client.settings.PolymorphicClientSettings`. The base `ServerSettings` and `ClientSettings` are now automatically polymorphic and you should use / inherit from those, instead.
- [MINOR] Changed the default settings class in `Client.settings_class` from `PolymorphicClientSettings` to `ClientSettings`.
- [MINOR] Changed the default settings class in `Server.settings_class` from `PolymorphicServerSettings` to `ServerSettings`.
- [MAJOR] Refactored the schemas in `LocalClientTransportSchema`, `LocalServerTransportSchema`, `RedisTransportSchema`, `StubClientTransportSchema, and `MetricsSchema` to support the new Conformity class schemas. This breaking change is only a disruption if you are using these classes directly. However, this is unusual and you are probably not. This does not break configurations that were processed by these schemas.
- [MAJOR] Deleted module `pysoa.common.schemas` and its classes `BasicClassSchema` and `PolymorphClassSchema`. This breaking change is only a disruption if you are using these classes directly. However, this is unusual and you are probably not.
- [MINOR] Previously, when a `Settings` object failed to validate against the settings schema, it might have raised `ValueError`, Conformity's `ValidationError`, _or_ `Settings.ImproperlyConfigured`. Now it will _always_ raise _only_ `Settings.ImproperlyConfigured` when it fails to validate against the settings schema.

0.61.2

-------------------
- [PATCH] Fix several tests broken by Conformity 1.25.0

0.61.1

-------------------
- [PATCH] Return same stub in multiple uses of the same stub_action instance
- [PATCH] Allow multiple uses of the same stub_action instance

Page 7 of 25

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.