v0.0.25

What's Changed

This fixes a locking/settlement issue in AzureTopic.subscribe by moving message settlement back onto the receiver-owned loop instead of settling from worker callback threads. It also tracks pending tasks and in-flight slots more explicitly so concurrency limits and max_receivable_messages remain accurate while messages are still processing.

Additional changes include lock-renew failure logging for better diagnostics on long-running jobs, new unit coverage for task settlement behavior, adding requirements.txt to the package manifest, and bumping the package version to 0.0.25.

Why This Fix Was Added

The previous flow settled messages from worker-thread callbacks while the receiver loop continued managing message intake. For long-running jobs, that creates a risk that receive, lock renewal, and complete/abandon operations fall out of sync, which can surface as lock-related failures or unreliable settlement behavior. The internal in-flight slot count also was not managed in a way that consistently reflected active work, so concurrency limits and bounded receives could become inaccurate under load. We added this fix to keep settlement in the receiver flow, make slot accounting deterministic, and improve diagnosis when lock renewal fails.

Impact

• Improves reliability of message completion and abandon handling for long-running Azure Service Bus consumers.
• Keeps in-flight concurrency tracking accurate so the subscriber does not over-receive while work is still running.
• Preserves max_receivable_messages behavior more predictably during active processing.
• Adds visibility into lock-renew failures through logging, which makes production issues easier to diagnose.
• Reduces the chance of message-processing instability caused by receiver/worker thread coordination.

• Fix Azure topic settlement flow for long-running messages by @sujata-m in #47
• [Main] Fix Azure topic settlement flow for long-running messages by @sujata-m in #48
• Updated package version by @sujata-m in #49
• Develop to Main by @sujata-m in #50

Full Changelog: 0.0.24...0.0.25

v0.0.24

What's Changed

• Add max_receivable_messages to topic subscribe by @susrisha in #45
• Develop to Main by @sujata-m in #46

Full Changelog: 0.0.23...0.0.24

0.0.23

What's Changed

• Fixed Task - 1467 by @sujata-m in #41
• Develop to Main by @sujata-m in #42

Full Changelog: 0.0.22...0.0.23

0.0.22

What's Changed

• Rewrote the azure topic for better control by @susrisha in #38
• Update version.py by @susrisha in #39
• Develop by @susrisha in #40

Full Changelog: 0.0.21...0.0.22

0.0.21

What's Changed

New Features and Enhancements

• Message Lock Renewal: Implemented a mechanism to automatically renew message locks during processing. This ensures that messages remain active and are not returned to the queue for reprocessing while they are being handled.
• Concurrent Message Processing: Enhanced the system to process messages concurrently using a number of worker threads equal to the number of available CPU cores by default. Users can override this default by specifying the max_concurrent_messages parameter, for example, core.get_topic(topic_name=topic_name, max_concurrent_messages=10). This optimization leverages system resources for improved performance and throughput.
• Completion Acknowledgement: Updated the processing flow to wait until message processing is fully completed before sending the acknowledgement of message completion. This change ensures reliable processing and accurate message handling.
• Version Tracking: Introduced a version.py file to maintain and track the package version. This addition facilitates version control and package management.
• Unit Test Updates: Updated unit test cases to cover the new features and enhancements, ensuring robust testing and quality assurance.
• Documentation Update: Updated the README file to reflect the new features and enhancements, providing clearer guidance and information for users.

Full Changelog: 0.0.19...0.0.21

0.0.19

What's Changed

• SAS URL generation done by @susrisha in #29
• Update freeze_version.py by @susrisha in #30
• Updated dependencies by @susrisha in #32
• Develop by @susrisha in #31

Full Changelog: 0.0.18...0.0.19

0.0.18

What's Changed

• Update topic.py by @susrisha in #27
• Package version changed- 0.0.18 by @susrisha in #28

Full Changelog: 0.0.17...0.0.18

v0.0.17

What's Changed

• Update README.md by @susrisha in #20
• Feature unit tests by @sujata-m in #21
• Added unit tests to cicd by @karthikkadajji in #22
• Rename org to projectgroup by @iAKM in #23
• Updated version by @sujata-m in #25
• orgId changed by @susrisha in #24

New Contributors

• @karthikkadajji made their first contribution in #22
• @iAKM made their first contribution in #23

Full Changelog: 0.0.16...0.0.17

0.0.16

0.0.16

• Removed extra logs

0.0.15

0.0.15

This fixes the inconsistent listening behavior for the subscription of a topic from core.

• Due to the usage of for message in receiver logic in the topic, it is unknown when the loop will end and the core will stop listening to the topic.
• This is tried with various combinations and figured out that at probably 4 hours from launch, this happens. The root cause for this is the socket / connection timeout of the underlying amqp client which throws an exception when trying to iterate next message

Fix made:

• The above for loop is kept in an infinite while loop which triggers the creation of the receiver and subsequent listening to the messages.
• This was tested overnight with messages varying in the time differences (1h to 3h)
• Specific method to look for the fix start_listening

Reference task:
302