Releases: kalaspuff/tomodachi
0.28.4
- When publishing to SNS, the AWS SNS+SQS transport resolves the topic ARN using
sts:GetCallerIdentity(to obtain the AWS account ID) andsns:GetTopicAttributeson the constructed topic ARN before falling back tosns:CreateTopic. This supports deployments where the service is not allowed to callsns:CreateTopicbut can publish to an existing topic with the usual AWS STS and AWS SNS read permissions. - Options now include
aws_endpoint_urls.stsfor configuring the AWS STS endpoint (for example with Localstack). If a custom endpoint is set foraws_endpoint_urls.snsbut not foraws_endpoint_urls.sts, the STS client falls back to the SNS endpoint URL for backward compatibility with existing configurations. - Extended the
types-aiobotocoredev dependency with thestsextra so STS clients are typed alongside SNS and SQS during development. - Dropped support for Python 3.9.
0.28.3
- Fixes an issue where the OTEL prometheus meter provider would start the prometheus exporter server although the service was not instrumented if an OTEL meter was created outside of the service' auto instrumentation scope. On hot reloads of code changes this would also cause the prometheus exporter server to be started multiple times, causing the service to fail to restart due to a port conflict.
- Fixes an issue in OTEL prometheus exporter target info where the service_name and job could be incorrectly set to "unknown_service" if an OTEL meter was created before the service was fully initialized and instrumented.
- Added jwcrypto to the list of safe modules that won't be cleared during the hot auto reload on code changes.
- Restricted version constraint of OTEL API / OTEL SDK to 1.27.0 until support for exemplar builder is fully implemented into tomodachi's aggregators.
0.28.2
-
Fixes a bug for AWS SQS queues with dead-letter queue configured which would trigger if SQS.DeleteMessage calls would unexpectedly fail or fail all retries for a message and the same message would be received again to the same consumer over and over again, where it would be ignored as a duplicated SQS message, until it would be sent to the DLQ. Even if the message was redrived to the queue and the same consumer would keep receiving it, it would still ignore the message as a duplicate. This would cause the message to be stuck in a loop.
Note that this change will run the handler function of the consumer after 60 seconds has passed and it receives the message again, which in a setup where a service has a single receiving consumer leaves responsibility of the handler to handle idempotency more strictly, in the same way as in setups with multiple consumers.
0.28.1
- Fixes an issue when attempting to call reading functions on a multipart web request in a handler would previously result in an "Could not find starting boundary in ..." error. This fix will now again make it possible to upload files as multipart web requests, and read those files from await request.post() in service http handlers. #1814
0.28.0
- Supports
aiohttp3.10.x versions. Dropped support foraiohttpversions prior to 3.9.5. - Enforces more recent versions of dependencies for OTEL (
>=1.27.0,>=0.48b0) when installed withopentelemetryextras. - Enforces more recent versions of protobuf (
>=4.25.0) when installed withprotobufextras. - Requires
yarlto use version 1.16.0+. - Support for Python 3.13. Python 3.13 has been added to test matrix and trove classifiers.
- Dropped support for Python 3.8.
0.27.2
0.27.1
0.27.0
Send messages directly to SQS queues (SQS.SendMessage)
-
Added the function
tomodachi.sqs_send_message(tomodachi.aws_sns_sqs_send_message) to send a message directly to an SQS queue. It mostly works the same way as thetomodachi.sns_publish(tomodachi.aws_sns_sqs_publish) function, but sends a message directly to the specified SQS queue.This is useful when you know the recipient queue of a message, for example when manually sending messages to a dead-letter queue or to do command-like messaging instead of event-based messaging.
-
The message body of
tomodachi.sqs_send_messagecalls is by default built using thetomodachi.transport.aws_sns_sqs.MessageBodyFormatterimplementation, which will encode the message body as JSON and embed it within the"Message"property also using the service specified message envelope functionality.The message includes some additional properties, mimicing how SNS notifications are represented when they are sent to subscribed SQS queues (with the exception that these messages are of type
"Message"to differentiate from SNS notifications that are by AWS typed"Notification".For custom or more advanced setups requiring more flexibility, the implementation can be overridden by providing a callable to the
message_body_formatterkeyword argument ofsqs_send_messagecalls. The callable receives a message context object and returns the raw message (as a string) that will be sent to SQS as the message body.Setting
message_body_formattertoNonewill disable default message body formatting (and incidentally also the message envelope builder), causing the message body to be as is specified within thedataargument to thesqs_send_messagecall. -
Trying to send messages to an SQS queue that does not exist will result in a
tomodachi.transport.aws_sns_sqs.QueueDoesNotExistErrorexception being raised, which can be caught also bytomodachi.transport.aws_sns_sqs.AWSSNSSQSException,botocore.exceptions.ClientErroror<botocore_sqs_client>.exceptions.QueueDoesNotExist.
Message attributes' improvements and fixes
-
Receives and propagates message attributes for all messages received on a queue, which means message attribute propagation will work for messages published to SNS, using either raw message delivery or not, and/or messages that were directly sent to SQS via SQS.SendMessage calls.
Currently, messages on SQS queues consumed and parsed by tomodachi services still need to be JSON formatted and be embedded within the
"Message"property (which is how SNS notification messages are represented by default, unless a queue is setup for raw message delivery). -
Fixes a bug that was causing message attributes in binary form to be invalidly processed.
OTEL updates
- OTEL auto instrumentation for the new
tomodachi.sqs_send_messagefunctionality. - OTEL attributes for AWS SNS+SQS messaging have been updated according to the latest OTEL semantic conventions, where the original publish destination is recorded as
messaging.destination_publish.name. - OTEL metrics for AWS SNS+SQS messaging uses the new metric instrument name
messaging.aws_sqs.duration, which was previously namedmessaging.amazonsqs.duration.
Type hints and input validation
- Additional support for the
types-aiobotocore-*packages to provide improved type hints internally. - AWS credentials provided to the aiobotocore connector are using stricter type hint annotations.
- Stricter argument validation when requesting aiobotocore connector clients to prevent issues caused by a mistyped AWS service, protecting against accidental use of wrong client for a specific service.
Handler arguments
- Added
message_type(str | None) to the list of keyword argument provided transport values that can be used in function signatures for AWS SNS+SQS handlers. Holds the value"Notification"for messages received as part of an SNS notification, unless the queue uses raw message delivery. In other cases the value is set to the value from a message body's JSON property"Type"if it exists. - Tailored for more advanced workflows, where more flexibility is needed,
raw_message_body(str) has also been added to the list of keyword argument provided transport values for AWS SNS+SQS handlers. Theraw_message_bodyvalue is set to the full content (non-decoded, as a string) from a received message'"Body", which can be used to implement custom listener with greater access to the raw message data. - Fixes an issue where the
topicargument to message handlers in functions was always populated with the value of thetopicargument to the@tomodachi.aws_sns_sqsdecorator, even if the message was sent to a different topic. Thetopicargument to message handlers in functions will now be populated with the actual topic name destination to where the message was published, if published via SNS. If the message was not published to a topic, the value is set to empty string.
Other
- Fixes issue where different OTEL tracers for the same
TracerProvidercould end up with different resource attributes, iff a service class'nameattribute's value were to be used as theservice.nameOTEL resource attribute (instead set to"unknown_service"for tracers that were created before the service initialized). - Multi-service execution won't accurately distinguish the service name of OTEL tracers, OTEL meters and OTEL loggers. In the rare case where there's multiple
tomodachiservices started within the same Python process, the name from the first instrumented service class will now be used as theservice.nameOTEL resource attribute for all tracers derived from the same tracer provider. The recommended solution if this is an issue, is to split the services into separate processes instead. - Refactoring of
tomodachi.aws_sns_sqs.get_queue_urlandtomodachi.aws_sns_sqs.get_queue_url_from_arnwith better support for additional types of input and/or potentially prefixing of queues. The function also now caches the queue URL to avoid unnecessary calls to the AWS API. - Support for
aiobotocore2.10.x releases and 2.11.x releases. - Documented the lifecycle termination process for services, for example when they receive a
SIGINTorSIGTERMsignal. Added details describing how handlers are awaited and for how long as part of the graceful termination sequence. - Converted repo documentation from RST format to Markdown. It finally happened.
0.26.4
- Fixes an issue with the custom backport class of
ConsoleRendererextendingstructlog.dev.ConsoleRenderer(which caused an exception to be raised upon service start, when usingstructlog23.3.0 or 24.1.0). - Uses the native
ConsoleRendererclass fromstructlogwhen a modern version ofstructlogis used (23.3.0 or newer).
0.26.3
- Updated version constraints of the
opentelemetry-exporter-prometheusdependency to use the correct (non-yanked) version range. Now>=0.40b0,<1.0.0from July 2023 and forward. Previously constrained to use the older, now yanked,1.12.0rc1version from May 2022. The 0.x releases ofopentelemetry-exporter-prometheusare more recent than the deprecated 1.x releases. - Support for
aiobotocore2.8.x releases and 2.9.x releases.